Re: [RFC] Null Namespaces

[Christian Brauner <brauner@kernel.org>]

> > > For my FD_FAILFS_ROOT proposal it would be enough if we make failfs
> > > SB_KERNMOUNT which means it's logically distinct from every mount
> > > namespace. I think that might be the right thing to do. I need to spend
> > > one or more brain cycles on this though.
> >
> > I had to take a long drive on Sunday and I kept thinking about both
> > FD_NULLFS_ROOT and FD_FAILFS_ROOT and ofc there are some things to
> > consider/discuss.
> >
> > I think the straightforward solution to FD_NULLFS_ROOT would be to just:
> >
> > - make it always available
> > - refer to the caller's mount namespace nullfs
> > - work with fchroot()/fchdir()
> >
> > So I considered two chroot() use-cases for the sake of simplicity:
> >
> > (1) You want to isolate yourself for the sake of lookup
> >
> > (2) You want to isolate yourself to assemble a "private mount tree" but
> >     not really be in a separate namespace (very odd use-case... but it
> >     helps to make a point).
> >
> > The problem with this approach is that everyone who chroots into the
> > nullfs root would suffer from the problem that any mount on top of it is
> > still visible. So that kinda makes it pointless for both (1) and (2).
> >
> > Also all mounts that someone else would do would also be visible
> > allowing multiple chroot()ers to affect each others state. That also
> > would somewhat defeat the purpose of the chroot(). So I'm not convinced
> > this is what we should do.
> >
> 
> After some contemplation and a long place flight: are we talking about
> nullfs or failfs?  Because I would expect that it's entirely

nullfs

> impossible to mount anything on top of failfs.  So failfs would be
> useless for #2 but would still solve #1.

Yes, failfs can't be mounted on at all.