Re: [PATCH RFC 4/7] fs: support FD_FAILFS_ROOT in fchroot()

On Thu, Jul 23, 2026 at 2:49=E2=80=AFPM Andy Lutomirski <[email protected]> w=
rote:
> On Thu, Jul 23, 2026 at 4:37=E2=80=AFAM Christian Brauner <brauner@kernel=
.org> wrote:
> >
> > Once entered, failfs is a throw-away-the-key moment. The task is
> > considered chrooted so it cannot create user namespaces to regain
> > CAP_SYS_CHROOT. chroot()/fchroot() back out require CAP_SYS_CHROOT.
>
> I kind of alluded to this earlier, but I don't think we should promise
> this.  In particular, I still think we should eventually allow a
> non-chrooted process with no_new_privs to chroot to any valid
> directory, and I think we should consider changing the definition of

FWIW, I kind of like that idea, but I think we need to look out for
how this interacts with path-based security checks and auditing.

Examples I can think of immediately are:

 - bpf_path_d_path() is intended for BPF LSMs that do
security/auditing, but uses d_path() which stops at the chroot.
 - audit_log_d_path() uses d_path()

These are already kinda broken in the face of unprivileged user
namespaces, but adding unprivileged arbitrary chroot() would break
them even more.