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

[Andy Lutomirski]

> On Jul 27, 2026, at 5:30 AM, John Ericson <mail@xxxxxxxxxxxxxx> wrote:
> 
> Very happy to see this patch series appear; thanks Christian!
> 
> Also happy with where this specific thread is going. I will just add
> that an additional flag in fs_struct to force RESOLVE_BENEATH in *all* path
> lookup would also be nice. The combination of:
> 
> root = pwd = failfs;
> chroot_locked = false;
> always_resolve_beneath = true;
> 
> 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.

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.

> 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
>