"Haelwenn (lanodan) Monnier" <[email protected]> writes:
> [2025-08-04 23:33:15+0100] Sam James: >>This lets us avoid suid in many cases and I can't see a reason to not >>do it. USE=caps generally means "use libcap (or libcap-ng) to have needed >>privileges, rather than suid". sys-libs/libcap is an unconditional dependency >>of important packages anyway like sya-apps/openrc, sys-auth/elogind, and >>sys-apps/systemd. >> >>There is an argument against filecaps/xattr by default, but we *do* >>enable those by default already and we just disable them for stages to >>allow portability and unpacking to exotic filesystems. >> >>Prompted by bug #961054 (which was a problem in another regard or two, >>but nonetheless reminded us about this). >> >>Bug: https://bugs.gentoo.org/961054 >>Signed-off-by: Sam James <[email protected]> > > I think it's a bit awkward to enable caps to disable suid, See below. There's two issues: 1) filecaps.eclass having strange behaviour where USE=-filecaps means you get suid by default (bug #811105), perhaps even if it's completely wrong 2) Having caps > suid when both are valid, legitimate options for a package. > they are quite different and that means USE=caps can mean granting > additional privileges instead of getting rid of suid. > > And it's not just future, like I'm noticing those two from a quick > grep caps profiles/use.local.desc > > dev-util/bpftool:caps - Use sys-libs/libcap to enable unprivileged run support > media-tv/kodi:caps - Use sys-libs/libcap to bind to privileged ports as > non-root > This is indeed a prickly bit. I'm not really sure what the alternative is. I see a few options: 1) We rename USE=caps in those packages to something else (what?) 2) We abandon USE=caps for the majority of packages and always have USE=suid toggle the other case, and USE=caps becomes for the bpftool/kodi/"more privileges, and if it's off, you get nothing" cases 3) 3a) We eat it and live with it 3b) We eat it and live with it but disable via package.use for some packages What else? > Instead I think ones like htop should have IUSE=suid, like bubblewrap > does for example. > This is tangential, I think. See the discussion in bug 811105. I think it's reasonable for us to simply not support suid for such cases unless someone files a bug making a compelling argument. (For htop, it wasn't even intentional.) > Best regards sam
