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.
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
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.
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
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
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.
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.
:) $ 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) => WONTFIXStatus: NEW => RESOLVED
Changing from wontfix to invalid since it's not a bug in the Mageia packages.
Resolution: WONTFIX => INVALID