On Wed, 2007-08-29 at 13:08 +0930, Tim wrote: > On Tue, 2007-08-28 at 08:36 -0400, Robert Locke wrote: > > /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. > > Though, I would have thought that the safest way to do that, would not > be for applications to directly read the file, but to query the system, > and the system read that file. > Much the same as how name look-ups are done. You ask the resolver, > which looks at a hosts file or uses a DNS server. You don't have each > application doing that role. > > I don't know how Linux does it, but in other systems, it is possible for > an application to open some file exclusively, and until its done with > it, nothing else can even read it. The potential for an application to > do such a dastardly thing with an important file would be a reason to > not directly use the files, as a matter of policy. > Well, it is a generic glibc call that most apps are using to do this, but, yes, they are reading the file. But, since they are using that library call, it is not opening it in any sort of "exclusive" mode. The lookup of this user information is done in a very similar way as your hosts example. All these lookups are using generic glibc calls controlled by a facility known as NSS (Name Service Switch), which allows applications to be transparently redirected to centralized databases of user, group, and other information (actually including hosts). The config file /etc/nsswitch.conf controls where they may get redirected to. Some distributions started playing with "nscd" which could function as a lightweight "resolver" daemon for NSS lookups which would include passwd, group, hosts, and had hoped to "speed things up a bit" by caching the information. The interesting part is that with that nscd daemon, it could become the only one that needed read access to the files, not the user making the glibc call. So I could theoretically remove other access from /etc/passwd (chmod o-r /etc/passwd), and ls -l still listed usernames rather than uids because they were supplied by nscd..... Not sure what the current state of nscd is, but it certainly whooped me in a class lecture once.... --Rob -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
