From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Description of problem:
Under certain conditions, /usr/bin/locate may reveal information of file
locations that would otherwise be protected based on filesystem permissions.
example: /home/userA/private can be revealed to userB
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. userA logs in, sets his home directory to 711 for things like web services
(public_html/ is an example...)
2. userA creates file /home/userA/private
3. userB logs in, and calls '/usr/bin/locate \* | grep "^/home/userA"
4. userB sees /home/userA/private, and performs 'cat /home/userA/private'
Actual Results: Results:
/home/userA/private was successfully viewed by userB
Expected Results: userB should not have been able to see that file as existing
from locate because the permissions on /home/userA were set to 0711 instead of
This scenario requires certain conditions to be met:
1) user must have their home directory set to 0711 (or at least the 'world'
execute bit) for things like web services and so-on.
2a) user must not have a modified bash_profile/bashrc file (nor on the system)
where the default umask is set to 022.
2b) user must not have modified the permissions of the file to remove world-
although these conditions are somewhat strict, from my experience most sites
that are webservers and have /home/user/ set to 0711 if public_html exists and
is available, and the umask is by default set to 022.
please also note that this 'bug' was marked as under 'security' for the
potential of 'information gathering'.
Is this still true?
tested with slocate-2.7, fixed.