With recent Linux versions file-based capabilities have been implemented. This means you can have the /bin/ping executables not setuid root, but simply with cap_net_raw capability set, allowing it just to use the RAW socket rather than executing part of it with full-fledged root privileges. This is a nice security mitigation technique. File-based capabilities can be set with the setcap(1) tool (from libcap package) but Portage will not copy them over when copying the file around. These values can't be accessed through xattr, but libcap itself should provide access to them, or the getcap(1) command could be used to get their value. This could be linked to USE flags for some packages so that setuid binaries can be replaced with file-based capabilities.
Wouldn't this only require some additional calls in pkg_postinst? If so, I don't see how portage is involved here.
I suspect general xattr support would be more worthy of a SoC project. On Linux that would get capability support for free, if I'm reading the libcap code correctly, although other OSes might do it differently. (In reply to comment #1) > Wouldn't this only require some additional calls in pkg_postinst? If so, I > don't see how portage is involved here. Probably cleaner to make the package manager preserve them across the merge. Assuming we do it that way, it'll need an EAPI bump, so adding pms-bugs.
getfattr can't list the capabilities so I wouldn't suspect that xattr alone would help.
the only thing portage needs to do is preserve caps from $D to $ROOT and make sure that when creating binpkgs, this info is preserved. same goes for ACLs or SELinux attrs and all that sort of fun stuff. not really a PMS issue nor worthy of SoC i dont think
Well, we could get SoC to adapt mtree to save and restore that data too, and then change portage to add an mtree output to the binpkg.
i'd like to avoid mtree if at all possible
But what to do in case FS does not support capabilities? Currently I'm thinking about fallback like this for wireshark: if ! setcap cap_net_raw,cap_net_admin+eip "${ROOT}"/usr/bin/dumpcap; then chmod 6550 "${ROOT}"/usr/bin/dumpcap fi Since $D and $ROOT may have different file systems (and thus different support for file-based capabilities) we need PM support here or are there better ways?
Constanze wrote an eclass for this during the past GSoC and it's ready for submission to -dev, I just need to cut out some time to get it sent and discussed. That eclass takes care of all the details already.
(In reply to comment #8) > Constanze wrote an eclass for this during the past GSoC and it's ready for > submission to -dev, I just need to cut out some time to get it sent and > discussed. > > That eclass takes care of all the details already. Any update, or a url to the thread? Not finding anything...
AFAIK: http://github.com/constanze/GSoC2010_Gentoo_Capabilities Also wireshark ebuild uses fcaps function similar to suggested in this work. I'm waiting for Diego to post RFC on -dev.
I guess this can be closed now.
we should update PMS to preserve xattrs since this affects all technologies that use those (selinux, filecaps, etc...)
But Portage doesn't preserve xattrs in all cases, does it?
Portage only preserves them when FEATURES=xattr is enabled, and the relevant file systems support it. If FEATURES=xattr is enabled and the $ROOT file system doesn't support it, Portage will abort while trying to merge the files (see bug 402323).
