News › linux
By The Linux Camp News, September 29, 2026
Failfs lets processes disable root- and working-directory-based lookups while retaining explicit directory descriptors. It is a self-sandboxing building block, not a guarantee of subtree confinement or irreversible entry.
Failfs, a filesystem designed to reject operations rather than store files, appears in Kernel Newbies’ Linux 7.3 changelog, updated September 28, 2026. Its implementation commit records Christian Brauner’s committer date as July 27. The feature lets a process replace its root and working directory with unusable lookup anchors while retaining access through explicit directory file descriptors. The sources retrieved September 29 establish the implementation and changelog listing, not a final Linux 7.3 release date. 1 2 5
The distinction from nullfs is deliberate: nullfs supplies an empty directory whose missing entries produce ENOENT, but the directory itself remains usable. Failfs returns EOPNOTSUPP, meaning the operation is unsupported. Brauner explains that permission errors would misleadingly suggest different credentials could succeed. Enforcement also covers paths that jump directly to the root: the VFS, Linux’s filesystem lookup layer, invokes a revalidation hook that failfs rejects, blocking O_PATH opens and file-handle creation through those routes. 6 7 2
Applications select the two restrictions separately. Calling fchdir(FD_FAILFS_ROOT), using a special descriptor value rather than an opened directory, disables working-directory-relative lookups, including dot and dot-dot, without requiring privileges. Explicit directory-descriptor lookups remain available. Giving the same sentinel to the new fchroot system call disables absolute paths and absolute symlinks. The practical consequence for applications adopting both is that required pathname access must start from retained directory descriptors, not from the working directory or an absolute pathname. 3 5 4
Root replacement has stricter entry conditions than working-directory replacement. In the supplied implementation, an unprivileged caller must have no_new_privs set, must not already be chrooted, and must not share its fs_struct, the kernel structure holding its root state. Callers with CAP_SYS_CHROOT in their user namespace bypass those three checks. Sandbox launchers therefore need to check all three conditions, rather than interpreting the changelog’s abbreviated mention of no_new_privs as the complete requirement. 5 1
Retaining a directory descriptor does not confine traversal to that directory’s subtree. A normal process root stops dot-dot traversal; replacing it with failfs removes that boundary from the real mount tree. Brauner’s commit explains that walking upward from a retained real directory descriptor can consequently reach the mount-namespace root. That is why already-chrooted unprivileged callers are rejected: failfs must not become a way to remove confinement imposed by a privileged manager. 5 2
Failfs is not a mount an operator creates or covers with another filesystem. The kernel creates one instance during early boot outside every mount namespace, so mounting over it fails. It cannot be cloned with OPEN_TREE_CLONE and is absent from mount listings and /proc/filesystems. For diagnosis, that absence is therefore not evidence that failfs is unavailable or unused. Reading a process’s proc root or cwd magic link can still reveal the string "failfs:/", even though following the link fails. 2 7
Sandbox designers should also review exit paths rather than assume entry is irreversible. Brauner explicitly makes no permanent one-way guarantee. His implementation-stage assessment says a task can prevent return by lacking or closing the relevant mount-namespace descriptors and restricting directory changes, root changes and setns through seccomp, the syscall-filtering facility. Descriptor management and syscall restrictions are thus part of that assessment, not protections supplied by failfs alone. 5 4