Re: [PATCH RFC 4/7] fs: support FD_FAILFS_ROOT in fchroot()
From: Christian Brauner <brauner@kernel.org>
Date: 2026-07-27 08:59:56
Also in:
linux-doc, linux-fsdevel, lkml
On 2026-07-27 00:57 -0700, Andy Lutomirski wrote:
quoted
On Jul 27, 2026, at 9:43 AM, Andy Lutomirski [off-list ref] wrote: quoted
goes along way to getting Capsicum's "capability mode".One thing I dislike about this is that it’s (approximately) a task mode. Why should an fd representing a capability represent one capability (a subtree) to one task but a different capability (dotdot) in a different task? Do we need to prevent unsharing a userns if this bit is set? Do we want to have to worry about any task that could potentially SCM_RIGHTS and fd to a task without that bit set? I prefer beneathness being an OFD property.Sigh, I keep thinking and typing OFD, and that won’t magically make it be correct. All these privilege restrictions applied to a file or path reference need to follow every user-controllable reference around correctly. So if I fchdir or fchroot to a restricted OFD, my cwd or root needs to preserve those restrictions, and reopening "/" or "." or any other path (via root or cwd or openat etc) needs to respect the restrictions as well. Putting it in struct path may or may not be a good idea.
I think making struct path carry more meaning than it does right now will cause us endless amounts of subtle issues. I fear that change very very much. That will have such a fundamental ripple effect across _all_ corners of the codebase that I'm very unwilling to be led down that road. And I think Al had traditionally similar reservations as me. One of the really thorny issues with the O_PATH upgrade masks was precisely the struct path modification.