Thread (23 messages) read the whole thread 23 messages, 6 authors, 6d ago

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

From: Jann Horn <jannh@google.com>
Date: 2026-07-23 14:08:12
Also in: linux-doc, linux-fsdevel, lkml

On Thu, Jul 23, 2026 at 1:30 PM Christian Brauner [off-list ref] 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...
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help