From: John Ericson <redacted>

This patch series allows processes to avoid having a root directory
and/or a working directory. The actual implementation is in the second
patch. The first patch just prepares some documentation. (Are struct
fields documented like this? Would this be good regardless?) And the
third patch adds unit tests.

I have tested these patches by `kunit.py run`-ing my new test suite.

The motivation is discussed at length in the thread starting with [1].
This patch would be the first in a series trying to allow for
less-privileged and more cheaply less-privileged processes than we have
today, by nulling out their namespace fields (or similar) so they do not
belong to any namespaces. This specific change is a prelude (in spirit,
it might actually be orthogonal in practice) to nulling out the mount
namespace, so that the process does not "belong" to any mount namespace.

Nothing creates such a task yet; the new UAPIs that would take advantage
of this feature are left as future work. It may not be appropriate to
submit such a "dead-code" patch, but I wanted to demonstrate just how
easy this change is (along with at least a unit test to exercise it),
before getting into UAPI designs.

The marquee new UAPI around this would, I hope, be the new non-fork-exec
process spawning API Li Chen started in [2]. The idea would be that,
instead of doing process initialization in the child post-fork, it is
done from the parent, against (my terminology) an "embryonic" (not yet
runnable; withheld from the schedule) process. These null fields
(`struct path` to directories in this patch, pointers to namespaces in
the latter patches to be written) allow for lightweight and minimally
privileged initial embryonic processes, allowing for good performance
(don't preemptively allocate things the caller may not want) and abiding
by the "principle of least privilege" (initialization should always
grant, not take away, privileges and resources from the embryonic
process).

So far in the linked discussion, the alternative that best addresses my
motivation is using the new "nullfs" for the root directory and cwd.
Practically, that is almost as good -- reading and statting the
directory will work, but it will reliably be and remain empty regardless
of how privileged the caller is. The downside is simply that we would
like those operations also to fail, to more readily signal to developers
and users (human or agent, for that matter) that the working directory
and root directory should be avoided, and paths should instead always be
paired with a file descriptor and used with `*at` or other modern UAPIs.

[1]: https://lore.kernel.org/all/a49ce818-f38d-41b0-bbf7-80b8aad998b1@app.fastmail.com/ (local)

[2]: https://lore.kernel.org/all/20260528095235.2491226-1-me@linux.beauty/ (local)

John Ericson (3):
  fs: Add documentation to some `struct fs_struct` fields
  fs: support tasks with a null root or cwd
  fs: add KUnit tests for tasks with a null root or cwd

 fs/Kconfig                     |  11 +++
 fs/cachefiles/daemon.c         |   6 +-
 fs/d_path.c                    |   6 +-
 fs/fhandle.c                   |   3 +
 fs/fs_struct.c                 |   4 +
 fs/namei.c                     |  22 ++++-
 fs/proc/base.c                 |   8 +-
 fs/tests/null_root_cwd_kunit.c | 147 +++++++++++++++++++++++++++++++++
 include/linux/fs_struct.h      |  29 ++++++-
 9 files changed, 228 insertions(+), 8 deletions(-)
 create mode 100644 fs/tests/null_root_cwd_kunit.c

-- 
2.51.2