Date: Mon, 19 Jul 2010 22:47:26 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-fs@freebsd.org Subject: Re: nullfs distinct path check: take into account filesystems Message-ID: <20100719194726.GZ2381@deviant.kiev.zoral.com.ua> In-Reply-To: <4C448432.5030009@icyb.net.ua> References: <4C03E9C0.2010602@icyb.net.ua> <20100602145856.GR83316@deviant.kiev.zoral.com.ua> <20100602151358.GS83316@deviant.kiev.zoral.com.ua> <4C448432.5030009@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--UQUSR6hGnEXrhNQw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 19, 2010 at 07:58:26PM +0300, Andriy Gapon wrote: > on 02/06/2010 18:13 Kostik Belousov said the following: > > On Wed, Jun 02, 2010 at 05:58:56PM +0300, Kostik Belousov wrote: > >> On Mon, May 31, 2010 at 07:54:24PM +0300, Andriy Gapon wrote: > >>> Right now mount_nullfs doesn't allow to, for example, mount / in > >>> /tmp/somedir even if /tmp is a different filesystem. I think there is > >>> no reason to do that and thus propose the following patch. > >> Reason is that after such mount "find /" would never end. > >=20 > > Hm, "different filesystems". Sorry, ignore my answer. >=20 > BTW, I thought about this some more and I think that you had a good point. >=20 > At present our nullfs is implemented to act only on a filesystem > level, not on a global namespace of file paths. That is, when I do > $ mount_nullfs target mountpoint I get under <mountpoint> only that > part of namespace that is rooted at <target> _and_ belongs to the same > filesystem as <target>. > > I think that this is an implementation detail, or implementation > choice, but not a characteristic feature of nullfs. > > I could imagine that nullfs could do global namespace "stitching" > regardless of underlying composition of the namespace (i.e. particular > filesystem hierarchy). In fact, such an implementation would seem more > natural and useful to me. > > Perhaps, we could add a mount option and a global sysctl to control > this behavior. Of course, the code would need to be written for that. > And we would have to be careful to not break POLA potentially with > security implications. > > What do you think? Current nullfs operates as vnode op bypass. E.g., when VOP_LOOKUP() is called on the nullfs vnode, VOP_LOOKUP() of the underlying filesystem on the underlying vnode is called. You proposal can only be implemented by calling namei() or lookup() from the nullfs_lookup(), effectively recursing into the VFS. It might work, but there are obvious complications, related to the unexpected lock ownership and stack depth, might be more. --UQUSR6hGnEXrhNQw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxEq84ACgkQC3+MBN1Mb4iU8gCg2DhO5zAdV2FZqj0WWdEFqhy8 hmwAoM+0Ajg5kG7E5UoD7Wf9y6dRzQuQ =L4yA -----END PGP SIGNATURE----- --UQUSR6hGnEXrhNQw--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100719194726.GZ2381>