Bug 252134 - locate can not open db files in dbpath
Summary: locate can not open db files in dbpath
Alias: None
Product: Fedora
Classification: Fedora
Component: mlocate   
(Show other bugs)
Version: 7
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Miloslav Trmač
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-08-14 05:38 UTC by Naveed Hasan
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-14 23:21:17 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
updatedb cron (349 bytes, text/plain)
2007-08-14 05:38 UTC, Naveed Hasan
no flags Details

Description Naveed Hasan 2007-08-14 05:38:42 UTC
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):


How reproducible:


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
/usr/bin/updatedb --require-visibility no --database-root /media/second --output

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

Priveleged user does not have this issue and can successfully search all db
files in dbpath.

Comment 1 Naveed Hasan 2007-08-14 05:38:42 UTC
Created attachment 161247 [details]
updatedb cron

Comment 2 Miloslav Trmač 2007-08-14 23:21:17 UTC
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

Note You need to log in before you can comment on or make changes to this bug.