Summary: | fcaps.eclass: pkg_postinst hook bypasses FEATURES=suidctl | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Bob's Your Uncle <garbage> |
Component: | Unclassified | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | aranea, dev-portage, perfinion, pr.gentoo-acct |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 467766, 548516 | ||
Bug Blocks: |
Description
Bob's Your Uncle
2013-03-08 18:46:05 UTC
Currenty, you can avoid it by enabling USE="filecaps", and enabling extended attributes on you file system. @base-system: Can the fcaps be done in src_install, so portage has a chance to apply suidctl? I'd rather not USE something I don't otherwise need or want to workaround this - I don't understand why that should be - this is a SUID binary and the SUID scan should detect it, simple as that. My kernel does not have support for extended attributes at all. How is it that this feature makes it work? The iputils ebuild calls the fcaps eclass function in pkg_postist, operating on files which have already been installed. This prevents portage from being able to scan the files. Portage could scan the files if the the ebuild would instead call fcaps in src_install (which operates on the ${D} directory containing the files that portage scans). (In reply to comment #1) fcaps can't be done in src_* because portage doesn't save/restore the filesystem extended attributes that are necessary for the whole thing to work we could probably add IUSE=+suid to fcaps.eclass and have it drop the set*id when that is not enabled (In reply to comment #4) > fcaps can't be done in src_* because portage doesn't save/restore the > filesystem extended attributes that are necessary for the whole thing to work It should work if FEATURES=xattr is enabled. (In reply to comment #5) is that guaranteed by PMS yet ? :) # ls -l /etc/portage/postsync.d/fcaps-eclass-hack -rwx------ 1 root root 161 May 15 16:13 /etc/portage/postsync.d/fcaps-eclass-hack # cat /etc/portage/postsync.d/fcaps-eclass-hack #!/bin/sh sed -i "s/mode=['\"]4711['\"]/mode='711'/" /usr/portage/eclass/fcaps.eclass sed -i 's/chmod \${mode}/#chmod ${mode}/' /usr/portage/eclass/fcaps.eclass *** Bug 553330 has been marked as a duplicate of this bug. *** I think the fcaps call could (and should) be moved to src_install without any relevant problems. There are three cases in which might moving fcaps to src_install would cause problems: (1) The / fs supports xattrs, but the /var/tmp/portage fs doesn't. Pretty unlikely unless someone misconfigured their kernel. (2) The copy operation during the merge step doesn't preserve xattrs. I haven't checked the other package managers, but for Portage this is pretty unlikely: With FEATURES=xattr the preservation is guaranteed, and otherwise is should still work in most cases (portage usually uses python's os.rename, which calls renameat(), which in turn preserves xattrs. (3) There might be problems with binpkg's. I don't know if this is actually the case for Portage, however. So, there are some rare problematic corner cases; but as the filecaps USE isn't enabled by default anywhere and users have to actively set it themselves, IMHO we can expect them to deal with any breakage that might ensue in those rare cases. Of course, an explanatory wiki entry wouldn't hurt (I could probably write one). On the plus side, performing the proposed change would be a huge win for FEATURE=suidctl users; silently breaking the guarantees suidctl is supposed to provide is really not cool(TM). And perfinion has indicated that it'd be useful for some portage patch he's currently working on, too. If there's interest in making this happen, I can prepare patches for the eclass and the ~15 affected ebuilds. Whoops, I'm sorry, turns out fcaps.eclass has USE=+filecaps, so filecaps is enabled by default. Of course, my previous argumentation doesn't apply anymore then. I'd suggest to disable the filecaps USE by default and proceed as previously proposed. |