On Mon, Aug 04, 2025 at 11:33:15PM +0100, Sam James wrote: > 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]>
+1 from me Albeit perhaps one thing that may be worth mentioning (at a glance) is util-linux[caps]. 1. it depends on libcap-ng rather than libcap 2. libcap-ng is pretty small, but when it's going to be pulled for almost *every* users when I think(?) "most" likely did not have it before may be worth thinking about (for me it's pulled by qemu either way but that has a more limited userbase) 3. util-linux[caps] only controls installing setpriv(1), it's IMO a nice/useful tool but afaik most users do not really know/use it and will more typically use `su -c` as root -- assuming that they need to do this at all Providing that by default still doesn't sound so bad (it's not suid-root unlike su, meant to be used by a privileged user), but moving it to IUSE=setpriv could be an option. Renaming USE does disrupt users like usual though and some users may rely on this tool for important scripts. I don't really mind either way myself, just thought it'd be worth mentioning. -- ionen
signature.asc
Description: PGP signature
