With SELinux enabled, packages that call python.eclass' python_merge_intermediate_installation_image will fail to install. The reason is that this method calls "cp --preserve=all" (which includes extended attributes) which will return non-0 because SELinux does not allow the portage_sandbox_t domain to "setfscreate". Allowing this in the policy might make it more troublesome, as this would result in the package' files to be installed on the file system with label portage_tmp_t. Generally, that's okay (portage will relabel afterwards to the correct label) but if the package itself offers the relabelling binaries, it might brake Portage / the system altogether. The latter still needs to be verified (one example of package that fails is policycoreutils which gentoo hardened manages itself ... just for SELinux). Reproducible: Always
A couple of alternatives to resolve this... 1/ Give portage_sandbox_t the setfscreate privilege. It doesn't need it per se (apart from making "cp --preserve=all" happy) but doesn't seem to harm the system (files installed do not suddenly get the portage_tmp_t label, so also setfiles isn't relabeled differently when the privilege is given, because there is no relabelto privilege) 2/ Use "cp --preserve=all --no-preserve=context" in said python.eclass function. The --no-preserve=context does not fail systems that are not SELinux aware, and it should cause SELinux-aware systems to continue gracefully. Testing this out right now.
The --no-preserve=context works. This would be my personal preference too. Arfrever, as you're apparently the developer that manages the python.eclass, what is your take on this? Could you validate if using "cp -fr --preserve=all --no-preserve=context" on line 1453 in python.eclass (instead of "cp -fr --preserve=all") is okay for you? I'd like to consider this as the preferential solution to this issue. Why? Well, because we do not want to preserve the contexts during the installation (merging) of a package from /var/tmp/portage/whatever to /. The contexts of the files will be wrong (all labeled portage_tmp_t) anyway. By copying files without preserving the context, the files inherit their parent's context (be it lib_t or bin_t) which usually is sufficient. After merging, Portage labels the files correctly anyway (from within the portage_t domain) using the setfiles command. I've also checked if we can "duplicate" the file context rules for / towards /var/tmp/portage/<whatever>/work but that tends to make things a *lot* more complicated.
Created attachment 277711 [details, diff] Suggested update to python.eclass This patch shows the suggested, small update to the eclass. It uses "cp -fr --preserve=all --no-preserve=context" to make sure that the SELinux context isn't part of the copying.
Fixed in python overlay.
Is in main portage tree (since october 7th).
