Bug 252134

Summary: locate can not open db files in dbpath
Product: [Fedora] Fedora Reporter: Naveed Hasan <naveed>
Component: mlocateAssignee: Miloslav Trmač <mitr>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 7   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-08-14 23:21:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
updatedb cron none

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):

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.
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
   /var/lib/mlocate.