Bug 933420 – [Future EAPI] Strip file capabilities, require those to be set in pkg_postinst

• Product: Gentoo Hosted Projects
• Status: CONFIRMED ---

[Description Florian Schmaus 2024-06-02 11:31:09 UTC]

File capabilities (and potentially suid & Co.) should be required to be stripped after src_install. Since their availability and support can only be decided when installing the package on the target system, they can only be reliable set in pkg_postinst (as fcaps.eclass already does).

As a bonus point, this would allow us to make fcaps.eclass more verbose when it installs files with capabilities (or suid).


Related #-dev discussion from 2024-05-04:

2024-05-04 11:27:06     @Flow   graaf's post to -dev, wondering if we should change fcaps.eclass behavior to treat empty FILECAPS not as error
2024-05-04 11:28:37     @Flow   fwiw, I don't have a strong opinion here. However, what bothers me a bit is that fcaps.eclass isn't more informative to the user about its actions.
2024-05-04 11:29:34     @graaff You mean something like einfo "Setting capabilities on …"
2024-05-04 11:29:42     @Flow   But that's probably only slightly related to a potential behavior change: allowing an empty FILECAPS would probably be more acceptable, if the eclass used einfo when setting fcaps or suid
2024-05-04 11:30:53     @Flow   graaff: right, I always wondered why the eclass isn't more explicit about that. It is certainly of interest to me as Gentoo user if a package installs files with suid or fcaps (but maybe that's just me)
2024-05-04 11:32:22     @graaff I don't think we strip capabilities and setuid in src_install(). Might be good to start doing that and then explicitly list everything that gets these elevated rights.
2024-05-04 11:32:54     @graaff Just fcaps.eclass reporting would give a false sense of security here, I think, since it wouldn't be complete.
2024-05-04 11:33:46     @Flow   fair point, and indeed PMS seems to say nothing about suid/fcaps
2024-05-04 11:34:41     @graaff My impression from the apache bug is that at least capabilities are currently broken since they may or may not be applied depending on the file system.
2024-05-04 11:34:59     @graaff So would be good to be more explicit about it.
2024-05-04 11:35:06     @sam_   see also the bug 814857 mess (only tangentially but it's related to graaff's comment wrt stripping things)
2024-05-04 11:35:07     +willikins      sam_: https://bugs.gentoo.org/814857 "sys-apps/portage: doexe preserves all xattrs, including ACL, from source file"; Portage Development, Core; CONF; slashbeast:dev-portage
2024-05-04 11:35:24      *      graaff imagines the carnage if we would strip this stuff all of a sudden. :-)
2024-05-04 11:36:13     @Flow   still, I wonder if this is something we could/should do in a new EAPI
2024-05-04 11:37:22     @graaff It would make things a bit more secure by being more explicit, but also a lot of work and unexpected breakage most likely.
2024-05-04 11:40:29     @dilfridge      that is exactly what could be done with a new EAPI
2024-05-04 11:40:55     @dilfridge      it only affects changed / updated ebuilds, new warnins could be introduced iff something is stripped, ...
2024-05-04 11:46:42     @sam_   graaff: I like this idea, by the way (the EAPI change for explicit)
2024-05-04 11:46:52     @sam_   consider writing it up in a bug?
2024-05-04 11:50:13     @sam_   graaff: IIRC we weren't actually affected by bug 930066 when I looked briefly, but we could've been easily
2024-05-04 11:50:14     +willikins      sam_: https://bugs.gentoo.org/930066 "<net-analyzer/netdata-1.45.3: ndsudo - local privilege escalation via untrusted search path"; Gentoo Security, Vulnerabilities; RESO, FIXE; arkamar:security
2024-05-04 11:50:30     <--     croaker (~croaker@gentoo/bot/croaker) has quit (Quit: transmission timeout)
2024-05-04 11:55:21     @graaff I've put it on my todo list...
2024-05-04 11:55:32     @sam_   thank you!
2024-05-04 11:55:42     @sam_   we're not in a rush for EAPI 9 anyway
2024-05-04 11:55:51     @graaff Or as I call it, my long term idea-preservation vault