On Tue, Mar 20, 2007 at 08:36:36AM -0400, Simo Sorce wrote: > 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 argument here is more about where to keep information about what is to be subindexed, not whether it makes security-wise sense to do so. Even so if the the .mlocate bits are only readable by the remote client if the remote client can traverse anyway through the filesystem, then there is no security leak anywhere. This means that either the remote filesystem is root-mounted w/o root_suqashing or a per-user authetication is put in place. In the former case only the non-suqashed root get's to read it (and is allowed to traverse the fs anyway since he's unsquashed) and in the latter you have set up per user trust (by nfs/krb or cifs) and setup any finer-grained security model suiting your site's needs. The default setup should asume the worst, e.g. have the indexes owned by root:root, so no remote fs old or new will be able to access the data if the admin of the server doesn't allow it. -- Axel.Thimm at ATrpms.net
Attachment:
pgpqN2HTYBSpg.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
