Re: [RFC] Null Namespaces

[Christian Brauner]

On Mon, Jun 29, 2026 at 10:50:38PM -0400, John Ericson wrote:
> On Mon, Jun 29, 2026, at 7:45 AM, Christian Brauner wrote:
> > But I guess the even simpler model would be to copy what I've been doing
> > for pidfs:
> >
> > [...]
> >
> > we then add fchroot() (overdue anyway) and then teach both fchdir() and
> > fchroot() to honor FD_NULLFS_ROOT. Then a process may shed its fs state
> > and move itself into nullfs. Restrict *chdir() and *chroot() for said
> > process via seccomp and it's locked in forever as well.
> 
> This looks good! It delivers most of what I want, and I do want to be
> very clear that while I am responding to your comments on my patch
> below, I would still be very pleased if we just did this, much more than
> I am pleased with the status quo.
> 
> (And also, yes, good to create the long-overdue fchroot regardless of
> what we do here.)
> 
> > Nothing here requires you to NULL anything and I oppose this on code
> > sanity reasons alone. We shoud absolutely not start to stash any NULL
> > pointers in core kernel objects such as struct path that are used
> > everywhere.
> 
> Before we do the "pidfd style" nullfs route, I want to make one thing
> clear about my patch: I was *not* trying to relax the invariant across
> the board that (live) `struct path` should only contain non-null
> pointers. Rather, I just want `struct fs_struct` to contain ("morally")
> `Option<struct path>`. My use of the null pointer was merely me doing
> the sort of ragged union packing that, for example, Rust does. I think
> as a matter of A_B_I (emphasis on "binary"), this is fine, and not
> going to cause Armageddon --- `struct path` is widely used, but `struct
> fs_struct` is (as far as I can tell) not.
> 
> All that said, as a matter of A_P_I (emphasis on "program"), I do see
> your point that it's too easy for someone to not read my comment, and
> then `struct path` with null pointers starts leaking all over the place,
> making a big mess. I think a simple enough fix is to just use another C
> encoding, such as a union, for `Option<struct path>`.
> 
> For example:
> 
>     union optional_path {
>         struct {
>             void *p0, *p1; /* must be null */
>         } __randomize_layout null_path;
>         struct path path; /* both fields must be non-null */
>     };
> 
> To continue saving space, or --- if relying on the overlap of
> `null_path` and `path.mnt` is too sketchy --- making a bona fide tagged
> union:
> 
>     struct optional_path {
>         enum {
>             OPTIONAL_PATH_ABSENT,
>             OPTIONAL_PATH_PRESENT,
>         } tag;
>         union {
>             struct {} null_path;
>             struct path path;
>         };
>     };

I think Al is about to have a stroke reading this... and I might too.
I agree with the sentiment I disagree with the details of this and
touching the whole kernel for this. You know what the easy solution is:
don't allow a struct path to be empty...