Filesystem-local databases in mlocate

Simo Sorce ssorce at redhat.com
Tue Mar 20 12:36:36 UTC 2007


On Tue, 2007-03-20 at 10:56 +0100, Axel Thimm wrote:
> On Tue, Mar 20, 2007 at 12:50:26AM +0100, Miloslav Trmac wrote:
> > Axel Thimm napsal(a):
> > > On Mon, Mar 19, 2007 at 11:51:19PM +0100, Miloslav Trmac wrote:
> > >> Hello,
> > >> Axel Thimm napsal(a):
> > >>>> * locate(1)'s default database is not just /var/lib/mlocate/mlocate.db;
> > >>>>   mlocate also checks each mounted filesystem for a .mlocate/mlocate.db
> > >>>>   file, owned by root or the invoking user, and not writable by anyone
> > >>>>   but the owner.  Such files are automatically added to the database
> > >>>>   path.
> > >>> locate should also include .mlocate/mlocate.db a previous updatedb has
> > >>> found and skipped. E.g. if updatedb detects a .mlocate/mlocate.db in a
> > >>> folder in its path it skips it and registers it for locate to use.
> > >> I can't think of a reason why they would be necessary.
> > > Consider for example a single volume nfs server exporting /home. So
> > > you want to have updatedb create a subdirectory-local db in /home, so
> > > it can be used on remote clients.
> > But on the client, where locate runs, /home/foo would be a separate
> > filesystem.
> 
> Yes, but updatedb (and locate) runs also on the server.
> 
> > As for updatedb,
> > > And instead of having to configure it in /etc/sysconfig it is easier
> > > to keep the metainformation of about where such .mlocate/mlocate.db
> > > should be maintained in the fs itself simply by creating the folder
> > > .mlocate.
> > wouldn't it be even more practical to support
> > FS_DB_GLOB=/srv/home/*
> > in /etc/sysconfig/mlocate ?
> 
> It's better not to have any knowledge under /etc of where special
> .mlocate/mlocate.db are injected on the (local) filesystem. Consider
> the (local) volume in question to be mounted from a SAN device, maybe
> even in a cluster active/passive setup. Or consider moving a data disk
> from one system to another.
> 
> It's better to try and keep the metainformation non-global (e.g. out
> of /etc) and self-describing, so it is rather transparent for the
> admin. Otherwise he needs to cater for any change of host <-> storage
> mapping in mlocate as well.

The more I think of it, the more I think .mlocate directories and files
are a very BAD idea. Security is not enforceable this way across
machines boundaries, so anything that shares the filesystem layout cross
machine IS a problem. The only way to solve the problem (and also avoid
the uglyness of having writable files all over the places, but keep them
in /var/cache where they should stay) is to have a network service that
use authentication mechanisms _per user_ (kerberized), and returns back
only the information such user is entitled to see.

Simo.





More information about the fedora-devel-list mailing list