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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
