nullfs distinct path check: take into account filesystems

[Kostik Belousov]

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.
> > 
> > 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?
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20100719/a7b08721/attachment.pgp