Date: Mon, 19 Jul 2010 19:58:26 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-fs@freebsd.org Subject: Re: nullfs distinct path check: take into account filesystems Message-ID: <4C448432.5030009@icyb.net.ua> In-Reply-To: <20100602151358.GS83316@deviant.kiev.zoral.com.ua> References: <4C03E9C0.2010602@icyb.net.ua> <20100602145856.GR83316@deviant.kiev.zoral.com.ua> <20100602151358.GS83316@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > Hm, "different filesystems". Sorry, ignore my answer. BTW, I thought about this some more and I think that you had a good point. 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? -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C448432.5030009>