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

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.

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 cwd) and their respective dotdots are fixed, quite cleanly, by this current patch set.

I also think it’s a bit of an ancient mistake that paths like /.. work at all instead of generating errors. Maybe a future beneath-only fd could also disallow trying to dotdot past the root, even for symlinks that contain dotdots.  This isn’t just an aesthetic thing - if I have ~/foo/bar being a symlink to ../bar, I think it would be a mistake for a beneath-only OFD to ~/foo to have “bar” resolve successfully to the wrong place.

quoted

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