Re: AppArmor for Fedora

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux