Re: [PATCH RFC 4/7] fs: support FD_FAILFS_ROOT in fchroot()
Andy Lutomirski <[email protected]> Mon, 27 Jul 2026 09:42:25 +0200
| Newsgroups | org.kernel.vger.linux-api,org.kernel.vger.linux-doc,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
> On Jul 27, 2026, at 5:30=E2=80=AFAM, John Ericson <[email protected]> wr= ote: >=20 > =EF=BB=BFVery happy to see this patch series appear; thanks Christian! >=20 > 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* pat= h > lookup would also be nice. The combination of: >=20 > root =3D pwd =3D failfs; > chroot_locked =3D false; > always_resolve_beneath =3D true; >=20 > goes along way to getting Capsicum's "capability mode". One thing I dislike about this is that it=E2=80=99s (approximately) a task m= ode. Why should an fd representing a capability represent one capability (a s= ubtree) 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 t= o 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) a= nd their respective dotdots are fixed, quite cleanly, by this current patch s= et. I also think it=E2=80=99s a bit of an ancient mistake that paths like /.. wo= rk 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 contai= n dotdots. This isn=E2=80=99t 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 =E2=80=9Cbar=E2=80=9D resolve successfully to the wron= g 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). >=20 > John >=20