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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20070212183234.GA7589@fieldses.org>
Date:	Mon, 12 Feb 2007 13:32:34 -0500
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Christoph Hellwig <hch@...radead.org>, Neil Brown <neilb@...e.de>,
	Andreas Gruenbacher <agruen@...e.de>,
	Trond Myklebust <trond.myklebust@....uio.no>,
	Tony Jones <tonyj@...e.de>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, chrisw@...s-sol.org,
	linux-security-module@...r.kernel.org, viro@...iv.linux.org.uk
Subject: Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/