Description of problem: Since recent upgrade from FC6 to F7, locate fails to operate as expected when run as unprivileged user. It searches in successfully only in default db and first valid user specified db. All following valid user specified dbs fail with "can not open ... permission denied". Version-Release number of selected component (if applicable): mlocate-0.16-1.x86_64 kernel-2.6.22.1-41.fc7.x86_64 How reproducible: Always. Steps to Reproduce: 1. Build auxiliary dbs as per attached cron file, e.g. - /usr/bin/updatedb --require-visibility no --database-root /media/first --output /var/lib/mlocate/first.db /usr/bin/updatedb --require-visibility no --database-root /media/second --output /var/lib/mlocate/second.db Permissions of db directory and contents - drwxr-x--- 2 root slocate /var/lib/mlocate -rw-r----- 1 root slocate /var/lib/mlocate/mlocate.db -rw-r--r-- 1 root root /var/lib/mlocate/first.db -rw-r--r-- 1 root root /var/lib/mlocate/second.db 2. For unprivileged user, set dbpath using LOCATE_PATH environment variable - export LOCATE_PATH=/var/lib/mlocate/first.db:/var/lib/mlocate/second.db 3. As same user, run locate with a query pattern. Actual results: locate LookingForAName ... results matching pattern in /var/lib/mlocate/mlocate.db ... ... results matching pattern in /var/lib/mlocate/first.db ... locate: can not open `/var/lib/mlocate/second.db': Permission denied Expected results: locate LookingForAName ... results matching pattern in /var/lib/mlocate/mlocate.db ... ... results matching pattern in /var/lib/mlocate/first.db ... ... results matching pattern in /var/lib/mlocate/second.db ... Additional info: If I transpose first.db and second.db in the LOCATE_PATH, locate comes back with results from second.db and fails on first.db - so the problem is not specific to the actual file permissions of second.db. It has something to do with the way all db files after the first user specified one are processed. If I have invalid file names in the LOCATE_PATH, there is an appropriate error for file not found and then the first file name that is valid is correctly searched and all following ones get the same permission denied error. I upgraded to mlocate-0.17-1 and later downgraded to mlocate 0.15-0.fc6.1 (which worked prior to my upgrade to F7) and rebuild all the dbs. Same problem still occurs. Priveleged user does not have this issue and can successfully search all db files in dbpath.
Created attachment 161247 [details] updatedb cron
Thanks for your report. The behavior you have observed happens because locate(1) gives up GID slocate before handling "untrusted" databases, to make sure unprivileged users cannot exploit possible bugs in locate(1) to gain GID slocate. More precisely, locate(1) gives up GID slocate immediately _after_ opening the first database that is not owned by group slocate, not readable by group slocate, or readable by "other" users. In your case, first.db is not owned by group slocate, so locate(1) gives up GID slocate after opening first.db. Actually, GID slocate is necessary for both first.db and second.db (because /var/lib/mlocate is rwxr-x---), but locate(1) doesn't detect that, so it incorrectly gives up the GID, and it can't open second.db. Ideally, locate(1) should be able to detect that GID slocate is necessary to read first.db and second.db. Unfortunately, it is not possible to detect that without race conditions. As a workaround, you can either 1) (chgrp slocate first.db second.db; chmod o-r first.db second.db), or 2) store first.db and second.db in a world-readable directory, not /var/lib/mlocate.