Created attachment 391558 [details] sample build log After updating portage to sys-apps/portage-2.2.14 emerge is no longer able to install any package, the unpack failes. All my gentoo systems are affected, all ore on stable and all packages current (emerge -a --update --deep --with-bdeps=y --newuse world). Updating the selinux-base and selinux-base-policy to 2.20141203-r1 does not help and updating all other selinux policies also to 2.20141203-r1 changed nothing. "setenforce 0" is allowing the package installation, so it must be selinux rules/rights/labels. "rlpkg -a -r" is not fixing the issue. Downgrading portage to sys-apps/portage-2.2.8-r2 is fixing the problem, so something must be done differently in the new portage version. Adding the following selinux rules is fixing the problem for real and I'm again able to emerge packages withportage-2.2.14 installed and enforcing enabled: allow sysadm_t portage_sandbox_t:process transition; allow portage_sandbox_t sysadm_t:fd use; allow portage_sandbox_t sysadm_t:process sigchld; That is the minimal set I have to use, removing one of the rights leads to a failure again, but not always to the same error message. Since these rules are granting the portage sanbox permissions for the sysadm_t that's may not the right fix. Here the selinux logs used to setup the rules above in the correct order: kernel: audit: type=1400 audit(1418467811.495:1257): avc: denied { transition } for pid=31418 comm="emerge" path="/usr/bin/sandbox" dev="sda3" ino=6369 scontext=staff_u:sysadm_r:sysadm_t tcontext=staff_u:sysadm_r:portage_sandbox_t tclass=process kernel: audit: type=1400 audit(1418468325.895:1303): avc: denied { rlimitinh } for pid=32442 comm="sandbox" scontext=staff_u:sysadm_r:sysadm_t tcontext=staff_u:sysadm_r:portage_sandbox_t tclass=process kernel: audit: type=1400 audit(1418468325.895:1304): avc: denied { siginh } for pid=32442 comm="sandbox" scontext=staff_u:sysadm_r:sysadm_t tcontext=staff_u:sysadm_r:portage_sandbox_t tclass=process kernel: audit: type=1400 audit(1418468325.895:1305): avc: denied { noatsecure } for pid=32442 comm="sandbox" scontext=staff_u:sysadm_r:sy kernel: audit: type=1400 audit(1418468614.655:1363): avc: denied { sigchld } for pid=580 comm="emerge" scontext=staff_u:sysadm_r:portage_sandbox_t tcontext=staff_u:sysadm_r:sysadm_t tclass=process During testing I had the additional rule allow sysadm_t portage_sandbox_t:process { siginh rlimitinh }; But later testing revealed that it's working without this line. The last rule, allow portage_sandbox_t sysadm_t:process sigchld; can according to audit2allow also be enabled be setting the boolean 'allow_ptrace'
It seems that the initial transition to portage_t is not working. Can you check the context of the emerge application file? It should be portage_exec_t: ~# ls -lZ /usr/lib/python-exec/python2.7/emerge -rwxr-xr-x. 1 root root system_u:object_r:portage_exec_t:s0 2603 Dec 7 10:40 /usr/lib/python-exec/python2.7/emerge ("emerge" is a symlink to python-exec which runs the above one afaics).
Yes, that is it: # ls -lZ /usr/lib/python-exec/python2.7/emerge -rwxr-xr-x. 1 root root system_u:object_r:bin_t 2603 13. Dez 11:18 /usr/lib/python-exec/python2.7/emerge # chcon -t portage_exec_t /usr/lib/python-exec/python2.7/emerge # ls -lZ /usr/lib/python-exec/python2.7/emerge -rwxr-xr-x. 1 root root system_u:object_r:portage_exec_t 2603 13. Dez 11:18 /usr/lib/python-exec/python2.7/emerge # restorecon /usr/lib/python-exec/python2.7/emerge # ls -lZ /usr/lib/python-exec/python2.7/emerge -rwxr-xr-x. 1 root root system_u:object_r:bin_t 2603 13. Dez 11:18 /usr/lib/python-exec/python2.7/emerge The emerge path has changed in the new portage. It was /usr/lib/portage/bin/emerge and is now something new: # which emerge /usr/bin/emerge # ls -alZ /usr/bin/emerge lrwxrwxrwx. 1 root root system_u:object_r:bin_t 31 13. Dez 11:18 /usr/bin/emerge -> ../lib/python-exec/python-exec2 # ls -alZ /usr/lib/python-exec/python-exec2 -rwxr-xr-x. 1 root root system_u:object_r:bin_t 1462 30. Nov 13:33 /usr/lib/python-exec/python-exec2 Setting semanage fcontext -a -t portage_exec_t /usr/lib/python-exec/python2.7/emerge and then restorecon /usr/lib/python-exec/python2.7/emerge fixes the issue.
This has already been fixed in 717d10b31cce2a5c92950c480444205a3c9ab839 it is in the -r1 policies which are in ~arch
r1 is now stable
