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

[Andy Lutomirski]

On Thu, Jul 23, 2026 at 7:09 AM Jann Horn <jannh@xxxxxxxxxx> wrote:
>
> On Thu, Jul 23, 2026 at 1:30 PM Christian Brauner <brauner@xxxxxxxxxx> wrote:
> > There's also some thought needed around shared fs_struct state. It's
> > obviously possible to chroot into failfs with a shared fs_struct if the
> > caller has CAP_SYS_CHROOT and shares the fs_struct or if the caller is
> > no_new_privs and shares the fs_struct. The non-chrooted-currently
> > requirement still applies.
>
> Having CAP_SYS_CHROOT and sharing the fs_struct should not be an issue
> because we already ensure that any tasks that share fs_struct are in
> the same user namespace, so CAP_SYS_CHROOT is implicitly also held
> relative to other users of the fs_struct. (In particular,
> userns_install() and unshare_fs() ensure this.) (Except if LSMs get
> involved with weird policy, I guess.) That's what makes the existing
> chroot() syscall safe.
>
> But yeah, the no_new_privs check I suggested is kind of a pain...
>

It's dorky, but we could say that your fs_struct must be non-shared
for unprivileged chroot to be allowed.

(I'm so mad at Docker for blocking *all* unshare calls in their
default policy.  Not a showstopper, but it's extremely annoying.  Yes,
I have an issue open that has been completely ignored.)