Merge tag 'vfs-7.3-rc1.failfs' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs

Pull failfs filesystem from Christian Brauner:
"Add failfs and expose a FD_FAILFS_ROOT sentinel.

This allo

Merge tag 'vfs-7.3-rc1.failfs' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs

Pull failfs filesystem from Christian Brauner:
"Add failfs and expose a FD_FAILFS_ROOT sentinel.

This allows userspace to shed their filesystem state completely. A
process with its root or working directory in failfs must anchor every
path lookup at an explicit file descriptor. Absolute paths, absolute
symlinks and AT_FDCWD-relative lookups simply fail.

Failfs is the counterpart to nullfs. nullfs says adds a permanently
empty, immutable directory whose lookups fail with ENOENT but which
can be opened, read, stat'd and mounted upon. Failfs on the other hand
fails every operation. The root cannot be opened at all. A single
instance is mounted during early boot via kern_mount(), which makes it
logically distinct from every mount namespace.

This is accompanied by a new fchroot() system call which makes
chrooting via a file descriptor a first class concept. It's possible
to chroot into failfs as an unprivileged user provided the task has no
new privileges set"

* tag 'vfs-7.3-rc1.failfs' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
Documentation: add failfs documentation
selftests/filesystems: add failfs selftests
arch: hookup fchroot() system call
fs: support FD_FAILFS_ROOT in fchroot()
fs: add fchroot()
fs: support FD_FAILFS_ROOT in fchdir()
fs: add failfs

show more ...

Merge patch series "fs: add failfs"

Christian Brauner <brauner@kernel.org> says:

nullfs provides a permanently empty and immutable directory. Lookups
fail with ENOENT. The directory can be opened,

Merge patch series "fs: add failfs"

Christian Brauner <brauner@kernel.org> says:

nullfs provides a permanently empty and immutable directory. Lookups
fail with ENOENT. The directory can be opened, read, stat, mounted upon.
It behaves like nothing is there.

Add its counterpart failfs where the semantics are not "there is
nothing here" but "nothing is supported here". Every operation that
reaches the filesystem fails with EOPNOTSUPP. Even statfs()/fstatfs()
fail so the filesystem cannot be discovered through an fd to it.

EOPNOTSUPP rather than a permission errno keeps that coherent. There
is no permission model in which anything could ever be allowed and
EACCES or EPERM would merely suggest that different credentials might
succeed while EIO would suggest corruption. It also makes hitting the
failfs boundary mostly quite dinstinguishable. A task anchoring its
lookups at real directory file descriptors may be able to tell a failfs
refusal from an ordinary permission failure. I wouldn't go so far as
guaranteeing that but it should mostly work.

The root cannot be opened at all not even with O_PATH. It is never
reached by a lookup in a parent directory. The only way to a path-walk
terminal at the root is a jump through a /proc/<pid>/{root,cwd} magic
link or by mountpoint traversal. The root also refuses
->d_weak_revalidate() which the VFS calls for jumped terminals. That
closes every remaining way to reference it. An O_PATH
open is refused and name_to_handle_at() cannot encode it into a file
handle, and following a magic link into it fails. A plain readlink() of
such a link still works and shows "failfs:/".

There is a single instance of failfs mounted during early boot via
kern_mount() making it logically distinct from every mount namespace.

Since the mount is a member of no mount namespace mounting onto it
fails. So nothing can ever be mounted on top of it. It cannot be cloned
via OPEN_TREE_CLONE and it does not show up in statmount()/listmount()
or /proc/<pid>/mountinfo. The filesystem is not registered so it is
not visible in /proc/filesystems and cannot be mounted from userspace.

This lets tasks shed their filesystem state completely. A process with
its root directory or working directory in failfs must anchor every path
lookup at an explicit file descriptor or is doomed to fail any lookup.
Absolute paths, absolute symlinks, and AT_FDCWD-relative lookups
simply fail. Followup patches will expose it via a new FD_FAILFS_ROOT
file descriptor sentinel understood by fchdir() and the new fchroot()
system call.

Fun fact, because of how dynamic binary execution work with PT_INTERP
this also currently prevents execution of dynamic binaries because
loaders have absolute paths (see selftests).

* patches from https://patch.msgid.link/20260724-work-failfs-v2-0-485dabbae185@kernel.org:
Documentation: add failfs documentation
selftests/filesystems: add failfs selftests
arch: hookup fchroot() system call
fs: support FD_FAILFS_ROOT in fchroot()
fs: add fchroot()
fs: support FD_FAILFS_ROOT in fchdir()
fs: add failfs

Link: https://patch.msgid.link/20260724-work-failfs-v2-0-485dabbae185@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>

show more ...

selftests/filesystems: add failfs selftests

Test the failfs semantics and both new entry points:

- fchdir(FD_FAILFS_ROOT):

* working directory lookups and getcwd() fail
* other sentinels are r

selftests/filesystems: add failfs selftests

Test the failfs semantics and both new entry points:

- fchdir(FD_FAILFS_ROOT):

* working directory lookups and getcwd() fail
* other sentinels are rejected
* the state is recoverable while the root is untouched

- fchroot() with regular fds:
* chroot parity
* CAP_SYS_CHROOT required
* ENOTDIR/EBADF/EINVAL checks

- fchroot(FD_FAILFS_ROOT):

* absolute lookups, stat, statfs and opens of the root including O_PATH fail with EOPNOTSUPP
* dirfd-anchored I/O keeps working
* ".." walks clamp at the top of the mount tree
* /proc magic links resolve but can't be stat through
* absolute symlinks fail while relative symlinks keep resolving

- Unprivileged entry requires no_new_privs and is rejected for
chrooted callers and for a shared fs_struct

- entering makes the task count as chrooted so user namespace creation
fails

- Nothing can be mounted on top of failfs and OPEN_TREE_CLONE is
rejected; the overmount test runs in a private mount namespace so a
regression cannot touch the host root

- setns() to a kept mount namespace fd restores root and working
directory

- The failfs root is inherited across fork() and absolute exec fails

- Exec by fd of a dynamically linked binary fails on opening its
absolute PT_INTERP interpreter

The exec tests run the exec in a child so a wrongly successful exec
cannot replace the test image and masquerade as a pass.

Link: https://patch.msgid.link/20260724-work-failfs-v2-6-485dabbae185@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>

show more ...