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

On 2026-07-27 00:57 -0700, Andy Lutomirski wrote:
> > On Jul 27, 2026, at 9:43 AM, Andy Lutomirski <[email protected]> wrote:
> >
> > 
> >>
> >> 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.