> Stands for Smart Filesystem Permissions. Before merging packages > to the live filesystem, automatically search for and set permissions > on setuid and setgid files. Files that are setuid have the group > and other read bits removed while files that are setgid have the > other read bit removed. See also suidctl below. The notion that a binary which contains setuid should not have read permissions for group/other users is a notion that once upon a time was seen a bit in upstream software. The basic idea is that you cannot attack a binary (or at least it is harder to attack a binary) if you don't know the exact bytes in the binary. This is short-sighted, because setuid binaries aren't the only ones that might be getting attacked. Logically, *all* binaries should be marked as "no read permissions" for security purposes, if any of them are. It's also generally a waste of time if one is distributing the binaries via a binhost, whether self-built or the one that currently ships identical setuid binaries to tons of Gentoo systems. It says something that AFAIK no binary-only distro has implemented this kind of blanket permission stripping. It's also generally a waste of time due to the security via obscurity principle... In short, use of sfperms provides minimal value if any. To set against that, I've recently been made aware of https://github.com/ivan-hc/Steam-appimage/issues/5 Short version: appimage is misdesigned, and tries to figure out which version of fusermount exists via manual path walking that involves opening up candidate files and attempting to read them. Without read permissions on fusermount, existing appimages in the wild fail to work. In an unrelated note, ugrd was trying to implement src_test handling to create an initramfs, including bundling the mount binary into an initramfs, which doesn't work unless the testsuite can actually, ya know, read the darned binary. Running a testsuite as root just for this seems... dumb. ;) I posit that sfperms is broken by design and should not exist. Since it exists anyway, and there's guaranteed to be at least one person who absolutely loves it and thinks that it's the secret to not getting pwned... we should just make it opt-in rather than opt-out. It is quite odd for portage to mess with reasonable file permissions of reasonable files with such thin justification.
I checked PMS to see if sfperms could be compliant, and found this: https://dev.gentoo.org/~ulm/pms/head/pms.html#section-13.3.1 > The package manager may reduce read and write permissions on executable files > that have a set*id bit set.
Looks like that was added in: commit c29a277be3eec6b4dd3afee0d71697dd6e07f209 Author: Ciaran McCreesh <ciaran.mccreesh@googlemail.com> Date: Thu Apr 24 19:44:08 2008 +0100 Document the merge process, take 2
Not much of an argument, but fwiw sfperms been giving me headaches with iwdevtools when attempting to show permission changes given image's and installed permissions aren't the same to compare in pkg_preinst. For now it's just documented as something I can't do anything about (like permission changes being done in pkg_postinst, albeit these aren't a widespread issue) and it shows false positives whenever e.g. fcaps.eclass is used.
(In reply to Ionen Wolkens from comment #3) > whenever e.g. fcaps.eclass is used err, meant to say any suid binaries rather, forgot that one just does 711 by default so removing sfperms wouldn't change anything
(In reply to Zac Medico from comment #1) > I checked PMS to see if sfperms could be compliant, and found this: > > https://dev.gentoo.org/~ulm/pms/head/pms.html#section-13.3.1 > > > The package manager may reduce read and write permissions on executable files > > that have a set*id bit set. It's the other way around. The sentence is in PMS because they were documenting existing Portage behaviour.
(In reply to Zac Medico from comment #1) > I checked PMS to see if sfperms could be compliant, and found this: > > https://dev.gentoo.org/~ulm/pms/head/pms.html#section-13.3.1 > > > The package manager may reduce read and write permissions on executable files > > that have a set*id bit set. I'm honestly not worried about whether sfperms is compliant. The feature exists, I assume at least one person uses it, removing the feature entirely feels almost spiteful. And we all know that PMS started off as documenting what portage *did*, so it's not surprising PMS describes this as allowed, either. I'd like it to be opt-in by the people who are positive they love the feature, rather than opt-out by people who don't know the feature exists but hit bugs they don't understand as a result of it. Because the feature is, one way or another, a footgun due to the reality of people having valid use cases for opening those binaries in read mode.
(In reply to Ionen Wolkens from comment #4) > (In reply to Ionen Wolkens from comment #3) > > whenever e.g. fcaps.eclass is used > err, meant to say any suid binaries rather, forgot that one just does 711 by > default so removing sfperms wouldn't change anything Right, we should probably discuss ebuilds/eclasses that set mode 1711 as well, though maybe in a separate venue.
A user hit this today: https://forums.gentoo.org/viewtopic-p-8845751.html.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f8642f4a3ef06b7b82985c9f770e5cda862adb54 commit f8642f4a3ef06b7b82985c9f770e5cda862adb54 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2024-11-11 00:59:40 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2024-11-18 16:43:00 +0000 fcaps.eclass: leave permissions alone by default Removing the read bit from suid binaries has questionable security benefit, and may cause problems for some software. Instead of clobbering the entire file mode, just toggle the suid bit if needed. In most cases this will result in a world-readable file. Introduce the FCAPS_DENY_WORLD_READ setting for users who insist on having their suid binaries unreadable. Skip calling chown/chmod if the owner/mode is empty. This may be used by ebuild authors in certain use cases. Bug: https://bugs.gentoo.org/938164 Signed-off-by: Mike Gilbert <floppym@gentoo.org> eclass/fcaps.eclass | 35 ++++++++++++++++++++++++++--------- 1 file changed, 26 insertions(+), 9 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=149971ceeeda2dc830bcad1e8e6b410989f76846 commit 149971ceeeda2dc830bcad1e8e6b410989f76846 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2024-11-10 22:04:06 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2024-11-11 01:31:27 +0000 make.globals: disable FEATURES="sfperms" by default Removing the read bit from suid binaries has questionable security benefit, and may cause problems for some software. Bug: https://bugs.gentoo.org/938164 Signed-off-by: Mike Gilbert <floppym@gentoo.org> NEWS | 3 +++ cnf/make.globals | 3 +-- 2 files changed, 4 insertions(+), 2 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=03f41049a0fe0632eabd8cddaaca898e45943201 commit 03f41049a0fe0632eabd8cddaaca898e45943201 Author: Sam James <sam@gentoo.org> AuthorDate: 2025-01-22 00:29:50 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-01-22 00:30:02 +0000 sys-apps/portage: add 3.0.67 Closes: https://bugs.gentoo.org/703520 Closes: https://bugs.gentoo.org/707980 Closes: https://bugs.gentoo.org/904702 Closes: https://bugs.gentoo.org/906044 Closes: https://bugs.gentoo.org/923530 Closes: https://bugs.gentoo.org/938164 Closes: https://bugs.gentoo.org/939299 Closes: https://bugs.gentoo.org/940120 Closes: https://bugs.gentoo.org/942512 Closes: https://bugs.gentoo.org/942760 Closes: https://bugs.gentoo.org/945382 Closes: https://bugs.gentoo.org/945861 Closes: https://bugs.gentoo.org/946326 Closes: https://bugs.gentoo.org/947822 Closes: https://bugs.gentoo.org/948067 Closes: https://bugs.gentoo.org/939444 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-3.0.67.ebuild | 231 +++++++++++++++++++++++++++++++++ 2 files changed, 232 insertions(+)
