Re: [RFC] Null Namespaces

[Christian Brauner <brauner@kernel.org>]

> > > I agree with the sentiment
> >
> > Thanks, I appreciate it :).
> >
> > > You know what the easy solution is: don't allow a struct path to be
> > > empty...
> >
> > Just so we're clear, my quibble here is purely behavioral: the nullfs
> > directory can be opened, right? And that open directory can also be
> > getdents64ed (yielding no entries, since it is empty), right? If I am
> > wrong about these things then sure, no objections from me --- let's ship
> > nullfs FDs right away!
> >
> 
> Christian, how would you feel about a variant of nullfs that fails all
> operations instead of acting as if it were empty?  (I'm far from
> convinced that this would actually be better, but it at least seems
> pretty straightforwardly possible.  And obviously the
> nullfs-at-the-root-of-everything would not want this variant.)

I think it would have to be a separate fs type: failfs. The problem is -
if taken to its logical extreme - it would have to refuse statfs and
fstatfs as well which means you can't discover it. You'd still be able
to get your cwd and root of course via /proc/self/{cwd,root}. So for
that we could just add:

FD_FAILFS_ROOT

I don't have quarrels with that. I can add that and it seems genuinely
useful. I'd again keep it as a kernel-only thing (not mountable) for now
until we have an idea whether the semantics work out...

(Btw, I've done something vaguely similar for kthreads in work to be
merged coming cycle. Their root and pwd are in a _separate_ nullfs that
can't even be overmounted. Which means you can't do arbitrary lookup or
I/O in init's fs state from kthreads anymore without having to use an
explicit scoped_with_init_fs() override with init's fs state
temporarily. Which means that hopefully things like ksmbd will not
happen again...)