[2025-08-06 02:36:58+0100] Sam James:
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
:(
Yeah, and of course fell right into that one as well even though
I'm also aware of the difference...
Given that I have no problems with making USE=caps default.
And yeah, I guess USE="caps" is too generic of a name...
Maybe could be USE=libcap, where if we ever need to toggle between
libcap and libcap-ng it would be via USE=libcap-ng?
Otherwise, making the description more explicit could help:
@@
-caps - Use Linux capabilities library to control privilege
+caps - Use Linux capabilities library to control privilege, for
file-capabilities see USE=filecaps instead
@@
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
Best regards
