When I call fcaps_pkg_postinst from pkg_postinst, the SETUID-bit is set with USE="-filecaps". It only happens when I call fcaps_pkg_postinst explicitly. When my ebuild does not override pkg_postinst, the bit is not set. Reproducible: Always Steps to Reproduce: 1. USE="-filecaps" emerge '=www-apps/gitea-1.14.6' 2. ls -l /usr/bin/gitea
(In reply to tastytea from comment #0) > When I call fcaps_pkg_postinst from pkg_postinst, the SETUID-bit is set with > USE="-filecaps". That is the intended behavior. > It only happens when I call fcaps_pkg_postinst explicitly. > When my ebuild does not override pkg_postinst, the bit is not set. www-apps/gitea inherits fcaps and go-module. Both of these eclasses export the pkg_postinst function. The last eclass to export the function wins.
(In reply to Mike Gilbert from comment #1) > (In reply to tastytea from comment #0) > > When I call fcaps_pkg_postinst from pkg_postinst, the SETUID-bit is set with > > USE="-filecaps". > > That is the intended behavior. Even so it is unexpected. Why would the eclass do anything if the functionality it provides is turned off via use-flag? I don't think many users are aware that they are getting suid binaries if they turn the flag off.
(In reply to tastytea from comment #2) > Even so it is unexpected. Why would the eclass do anything if the > functionality it provides is turned off via use-flag? Well, behavior is documented[1] so I wouldn't call it unexpected. Can debate that the behavior is not great, but please read docs of eclasses you use. [1] https://devmanual.gentoo.org/eclass-reference/fcaps.eclass/index.html
This has been the documented behavior of the eclass for many years. fcaps is typically used for binaries that would normally be installed suid on a traditional UNIX system. On Linux, file-based capabilities allow us to reduce the privilege level from full superuser access. gitea is using fcaps.eclass for a somewhat different purpose: it is giving additional permissions to the gitea binary instead of taking them away. You would not normally install a web application with the suid bit set and a root owner. If you don't want to default the non-caps mode to 4711, set FILECAPS like so: FILECAPS=( -m 0755 cap_net_bind_service+ep usr/bin/gitea )
(In reply to Mike Gilbert from comment #4) > This has been the documented behavior of the eclass for many years. It is documented for the function fcaps. It was not clear to me (and apparently the original author of that ebuild) that fcaps_pkg_postinst calls fcaps with USE="-filecaps". > fcaps is typically used for binaries that would normally be installed suid > on a traditional UNIX system. On Linux, file-based capabilities allow us to > reduce the privilege level from full superuser access. From a users perspective, it is confusing that a binary will have more privileges when I tell portage to not add extra privileges. Especially since we have a suid useflag.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e798e0e9c7a13b2004cb492901a8e2873388cbe9 commit e798e0e9c7a13b2004cb492901a8e2873388cbe9 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2021-08-30 15:05:55 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2021-08-30 15:05:55 +0000 www-apps/gitea: set non-caps mode to 0755 Running a web application as root is insane. Bug: https://bugs.gentoo.org/811105 Signed-off-by: Mike Gilbert <floppym@gentoo.org> www-apps/gitea/gitea-1.14.6.ebuild | 2 +- www-apps/gitea/gitea-9999.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
I suppose it might be safer to have the eclass default to a non-suid mode, and override that in ebuilds that require suid fallback behavior for USE=-filecaps.
