On Tue, 2007-08-28 at 13:11 +0930, Tim wrote: > On Mon, 2007-08-27 at 21:55 +0100, Alan Cox wrote: > > The passwd file isn't considered secret in any way. Its public > > readable data. The /etc/shadow file holds passwords and is root only. > > I thought that's only because we, now, have passwords stored in another > location. It used to contain passwords. Maybe it still does with some > distros. > > ll /etc/passwd > -rw-r--r-- 1 root root 2175 2007-08-19 15:56 /etc/passwd > > Not quite "root only." Sure, only root can change it, but others can > read it. > Tim, /etc/passwd has always been "universally" readable. As a quick example, note your use of "ll" which is really "ls -l" and the fact that the third and fourth columns are displaying "names" of the user and group associated with that file. The reality is that the "names" are not stored on disk, but rather their numeric representation: uid and gid. In order for the ls command to display a name, it needs to "look up" the user's name associated with the uid it got from the filesystem. Where is this "mapping" of uid and username kept? Yep, /etc/passed. Likewise, /etc/group is universally readable to allow lookups of gid to group name. The general consensus has always been that the "information" kept in /etc/passwd and /etc/group are considered "public" information. Passwords have been "moved" to a "private" file called /etc/shadow (and /etc/gshadow), because of the potential for "dictionary attacks" on the encrypted password if all users could access that too. Look at "pwconv" and "pwunconv".... But how public do we really want to be, even with the /etc/passwd fields that remain? While most authenticated, interactive users on my system might need to access /etc/passwd to get proper output from /bin/ls, do all my daemons/services running in the background need that access? Does my DNS server really need to "look up" anything in /etc/passwd? So, as this thread started, these MAC-level security layers allow me to create more granularity in restricting users and services, but now in a "central" policy that can be "role" based.... HTH, --Rob
