Re: [PATCH RFC 4/7] fs: support FD_FAILFS_ROOT in fchroot()
Jann Horn <[email protected]> Thu, 23 Jul 2026 16:07:33 +0200
| Newsgroups | org.kernel.vger.linux-api,org.kernel.vger.linux-doc,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAG48ez1psv82Y98XT1p7vujYgj5a9hbPZ4=h7x4-yXQO5FQr6A@mail.gmail.com> |
On Thu, Jul 23, 2026 at 1:30=E2=80=AFPM Christian Brauner <[email protected]= rg> 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...