up vote 18 down vote favorite
share [g+] share [fb]

ls -l /etc/passwd

gives

$ ls -l /etc/passwd
-rw-r--r-- 1 root root 1862 2011-06-15 21:59 /etc/passwd

So an ordinary user can read the file. Isn't this a security hole ?

link|improve this question
60% accept rate
1  
It has to be readable so you can map an id number to a login name, for instance. – Paul Tomblin Jul 4 '11 at 0:45
feedback

migrated from stackoverflow.com Jul 4 '11 at 0:27

This question came from our site for professional and enthusiast programmers.

5 Answers

up vote 44 down vote accepted

Actual password hashes are stored in /etc/shadow, which is not readable by regular users. /etc/passwd holds other information about user ids and shells that must be readable by all users for the system to function.

link|improve this answer
2  
Not really - historically passwords were kept in /etc/passwd - but this made brute-force matching straightforward - hence modern systems using /etc/shadon with pam_unix and similar. – symcbean Jul 4 '11 at 12:20
feedback
up vote 15 down vote

Typically, the hashed passwords are stored in /etc/shadow on most Linux systems:

-rw-r----- 1 root shadow 1349 2011-07-03 03:54 /etc/shadow

(They are stored in /etc/master.passwd on BSD systems.)

Programs that need to perform authentication still need to run with root privileges:

-rwsr-xr-x 1 root root 42792 2011-02-14 14:13 /usr/bin/passwd

If you dislike the setuid root programs and one single file containing all the hashed passwords on your system, you can replace it with the Openwall TCB PAM module. This provides every single user with their own file for storing their hashed password -- as a result the number of setuid root programs on the system can be drastically reduced.

link|improve this answer
feedback
up vote 11 down vote

Passwords haven't been stored in /etc/passwd for years now; the name is legacy, the function of being the local user database remains and it must be readable by all for that purpose.

link|improve this answer
2  
world readability is a design decision, not a necessity – Ben Voigt Jul 4 '11 at 0:11
@Ben: so it's reasonable that nobody can identify files that belong to someone else? It's the local store for NSS these days, not for PAM despite its name. – geekosaur Jul 4 '11 at 0:14
1  
It's entirely possible to have a privileged service do uid -> name translation, without allowing unprivileged users to enumerate the entire user list. Some OSes choose that option. – Ben Voigt Jul 4 '11 at 0:17
1  
@joechip Current OSes are not designed to hide users from each other. All users can be enumerated in many more ways than /etc/passwd. ls -la /home on Linux, ls -la /Users on MacOS X, dir C:\Users in windows 7, ps -afux in Unix systems. Changing the design choice Ben Voigt alluded to just makes life difficult without changing security. – Magicianeer Jul 4 '11 at 5:05
1  
@Magicianeer - Just saying the Windows example isn't quite right. You can get the users through other methods, but looking at the C:\users folder will only list users that have logged in; not any system users. – burnt_hand Jul 4 '11 at 9:18
show 5 more comments
feedback
up vote 4 down vote

To some extent it is, as you can identify users. In the past you could also pick up their passwords. However, the one userid really worth cracking is root which is well known without the password file.

The utility of having the password file world readable generally far outweighs the risk. Even if it weren't world readable, a functioning getent passwd command would render the security gain void.

The ability for non-root users to identify files owned by others would disappear. Being able to identify owned (user in passwd file) and unowned files (user not in passwd file) can be useful in reviewing the contents of a file system. While it would be possible to resolve this with appropriate setuid programs, that would add a huge attack vector via those programs.

In the end it is a matter of balance, and in this case I would say the balance is firmly on having password world readable.

link|improve this answer
feedback
up vote 3 down vote

The user passwords are not stored in /etc/passwd anymore. This explains how the shadow password mechanism works: http://en.wikipedia.org/wiki/Shadow_password

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.