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
