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