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

> On Jul 27, 2026, at 9:43=E2=80=AFAM, Andy Lutomirski <[email protected]=
> wrote:
>
> =EF=BB=BF
>>
>> goes along way to getting Capsicum's "capability mode".
>
> One thing I dislike about this is that it=E2=80=99s (approximately) a tas=
k 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 w=
e want to have to worry about any task that could potentially SCM_RIGHTS an=
d fd to a task without that bit set? I prefer beneathness being an OFD prop=
erty.

Sigh, I keep thinking and typing OFD, and that won=E2=80=99t 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.

And, if we allow cloning a restricted reference to a subtree to mount
it, we need to make that work correctly too.

Off the top of my head, for a minimum viable product, we could
disallow cloning/mounting from a restricted reference.  And if we want
to try delegation (as in my other braindump email), we could try
*only* allowing delegation via clones/mounts and not in an OFD or cwd
or root, since there are potentially mildly thorny or at least
unintuitive interactions between symlinks and privilege delegation,
especially if mounts can delegate.  (And I think that delegation via
OFD/cwd/root but not via mount is so weak that there's almost no point
-- I want to delegate to a container, and that requires mounts.)

>
> Note that the obvious giant holes in capsicum-without-a-mode (root and cw=
d) and their respective dotdots are fixed, quite cleanly, by this current p=
atch set.
>
> I also think it=E2=80=99s a bit of an ancient mistake that paths like /..=
 work at all instead of generating errors. Maybe a future beneath-only fd c=
ould also disallow trying to dotdot past the root, even for symlinks that c=
ontain dotdots.  This isn=E2=80=99t just an aesthetic thing - if I have ~/f=
oo/bar being a symlink to ../bar, I think it would be a mistake for a benea=
th-only OFD to ~/foo to have =E2=80=9Cbar=E2=80=9D resolve successfully to =
the wrong place.
>
>> Then we just
>> need to figure out things like more capabilities for directory file
>> descriptors per Andy's brainstorming thread thread (which I ought to get
>> to replying to).
>>
>> John
>>