Filesystem-local databases in mlocate

[Axel Thimm]

On Tue, Mar 20, 2007 at 08:28:51AM -0400, Simo Sorce wrote:
> On Tue, 2007-03-20 at 00:12 +0100, Miloslav Trmac wrote:
> > Simo Sorce napsal(a):
> > >> - NFS is automatically excluded by clients, so updatedb on clients
> > >>   does not walk the filesystem.
> > >> - On the server:
> > >>   Add /srv/home to /etc/sysconfig/mlocate.  If /srv/home is not a
> > >>   separate mount point, add LOCATE_PATH=:/srv/home/.mlocate/mlocate.db
> > >>   to the global environment.
> > > I am deeply concerned about the security implications of this idea.
> > > You are basically making it possible for everyone to get access to the
> > > complete remote FS layout ???
> > No, only the layout of the specific NFS filesystem that can be mounted
> > from the client.
> 
> This is what I am talking about, the whole remote (exported) FS.
> 
> >   mlocate.db would be readable only by the slocate user,
> > like the current /var/lib/mlocate/mlocate.db.
> 
> You are thinking in 1990 terms (NFSv3), how do you authenticate the
> slocate user on NFSv4 and CIFS?
> 
> > Therefore, if a client can fake the UID and read the whole mlocate.db,
> > it can fake the UID and traverse the whole NFS filesystem just the same.
> 
> You are thinking in 1990 terms (NFSv3), in 2007 we have CIFS and NFSv4
> that authenticate per user, such a file would be a considerable security
> breach, on these file systems.

Why, on these filesystems (assuming the proper authentication mechanism
is in place) you cannot fake the uid anymore, so you have even less
access rights to any root owned file. It's the elder, fakable
protocols that need attention.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070320/606200d6/attachment.sig>