Sam James <[email protected]> writes: > "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
I should say that making USE=suid do this would likely be unpopular, given it's not very future-looking (weird to start introducing a USE flag all over the place when users will usually want it *off* and the thing the USE flag is named after (suid) is considered on-the-way-out.) > 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
