Bug 30166

Summary: locate: permission denied on /var/lib/mlocate/mlocate.db
Product: Mageia Reporter: Pierre Fortin <pfortin>
Component: RPM PackagesAssignee: Jani Välimaa <jani.valimaa>
Status: RESOLVED INVALID QA Contact:
Severity: enhancement    
Priority: Normal CC: davidwhodgins
Version: Cauldron   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Source RPM: CVE:
Status comment:

Description Pierre Fortin 2022-03-13 02:39:23 CET
Description of problem:  Tried using locate as normal user and got:

$ locate foo
locate: can not stat () `/var/lib/mlocate/mlocate.db': Permission denied

-rw-r----- 1 root mlocate 17079848 Mar 12 00:00 /var/lib/mlocate/mlocate.db

Version-Release number of selected component (if applicable): up-to-date Cauldron on:
Operating System: Mageia 9
KDE Plasma Version: 5.23.4
KDE Frameworks Version: 5.88.0
Qt Version: 5.15.2
Kernel Version: 5.16.14-server-1.mga9 (64-bit)
Graphics Platform: X11
Processors: 20 × 12th Gen Intel® Core™ i7-12700K
Memory: 62.5 GiB of RAM
Graphics Processor: AMD Radeon RX 6600 XT

Tried:
# chown mlocate /var/lib/mlocate/mlocate.db
chown: invalid user: ‘mlocate’
Yup, no such user in /etc/passwd...


How reproducible: always


Steps to Reproduce:
1. issue:  locate <some_string>
2.
3.
Comment 1 Dave Hodgins 2022-03-13 02:52:18 CET
I don't have Cauldron running right now.

On Mageia 8 ...
$ ll /var/lib/mlocate
total 64100
-rw-r----- 1 root mlocate 65632433 Mar 12 00:00 mlocate.db

$ grep mlocate /etc/passwd /etc/group
/etc/group:mlocate:x:487:dave

The user must be a member of the mlocate group. There is no mlocate user.

CC: (none) => davidwhodgins

Comment 2 Dave Hodgins 2022-03-13 02:57:54 CET
Forgot to include, add your id to the mlocate group, logout/in and confirm
mlocate then works. If that's the case (mlocate group does exist), close this
bug as invalid.
Comment 3 Pierre Fortin 2022-03-13 03:32:01 CET
Hmm... I'll do that; but... I don't think requiring new users to learn about extra permissions for basic commands is appropriate. Maybe updatedb, as it's building/updating its db, should, when it finds files owned by a user not in its mlocate group, be responsible for adding such new user(s) to said group.  That would be safer and more security conscious than having a normal user messing around as root. Especially in a controlled corporate environment where such normal user doesn't have root access...

Changing to enhancement.

Severity: normal => enhancement

Comment 4 Dave Hodgins 2022-03-13 04:21:21 CET
It's pretty standard method for files that are intended to be accessed by more
than one, but not necessarily all users it's the same as on other linux
distributions, so I expect the request to be refused. Assigning to the
registered maintainer, to decide.

Assignee: bugsquad => jani.valimaa

Comment 5 Pierre Fortin 2022-03-13 17:44:21 CET
Been using Linux since 1998, and can't recall ever hitting this issue before. Hopefully, there's some way to avoid having to waste time figuring out how to fix this.  Thanks for not outright dumping the report.
Comment 6 Dave Hodgins 2022-03-13 18:08:59 CET
Also, from https://pagure.io/mlocate ...
Installation
============
Before installation it is necessary to create a group called "mlocate" to allow
hiding the contents of the database from users.

When updatedb is run by root, the database contains names of files of all
users, but only members of the "mlocate" group may access it.  "locate" is
installed set-GID "mlocate", no other program should need to run with this GID.
==================================================
It's been 5 years since there were any changes to mlocate and much longer since
there were any changes other than translations.

Note that a user can run updatedb themselves, for files that they have
access to.

Now that I'm mostly using ssd drives, I tend to use
"tree -ifa <path>|grep whatever" instead.
Comment 7 Pierre Fortin 2022-03-13 19:45:25 CET
:)
$ updatedb
updatedb: can not open a temporary file for `/var/lib/mlocate/mlocate.db'

5 years:  it's been about that long since I last did a cold install like I just did on this new system. Years ago, I used to keep a "pre-flight checklist" for things to check upon a new install...

Thanks

Resolution: (none) => WONTFIX
Status: NEW => RESOLVED

Comment 8 Dave Hodgins 2022-03-13 20:02:14 CET
Changing from wontfix to invalid since it's not a bug in the Mageia packages.

Resolution: WONTFIX => INVALID