Sam James <[email protected]> writes: > 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.)
I realise now that the premise is mistaken and my commit message was wrong: USE=caps doesn't help us avoid suid, it helps us drop privileges more often in general. It's not the same as USE=filecaps. See, I know the difference, and I still keep mixing them up! Bad naming :( > >> 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
