Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, Feb 06, 2007 at 10:37:37AM +0000, Christoph Hellwig wrote:
> On Tue, Feb 06, 2007 at 09:26:14PM +1100, Neil Brown wrote:
> > What would be the benefit of having private non-visible vfsmounts?
> > Sounds like a recipe for confusion?
> > 
> > It is possible that mountd might start doing bind-mounts to create the
> > 'pseudo filesystem' thing for NFSv4, but they would be very visible
> > (under /var/lib/nfs/v4root or something).
> > So having it's own vfsmount might make sense, but I don't get
> > 'non-visible'.

> It would allow creating an exported tree without interferance with
> the local visible tree.  Note that the local visible tree isn't
> global anymore either, and this allows to adjust what's exported
> through nfsd throug a specific interface instead of needing to
> get into nfsd namespace through some way.

What would this interface look like?  Would it be a user<->kernel
interface, or a user<->mountd interface?

Tentatively what I was thinking of was having mountd fork off its own
namespace, use /etc/exports to construct a mount tree there, then pass
that mount tree down to the kernel using the existing exports cache
channel.  Name resolution in svc_export_parse should be done in mountd's
namespace, so I think this works.

> Think of listing the actually exported devices in /etc/exports instead
> of the indirection through fstab aswell.

Hm.  We'd have to add mount options to /etc/exports too if we were going
to do that, right?

--b.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/