emerge fails if running from nfs while selinux is enforcing Reproducible: Always Steps to Reproduce: mount /usr/portage with nfs set selinux to enforcing emerge something (pango was my test) Actual Results: >>> Emerging (1 of 1) x11-libs/pango-1.28.4 Traceback (most recent call last): File "/usr/lib64/portage/pym/_emerge/EbuildFetcher.py", line 113, in _spawn allow_missing_digests=False): File "/usr/lib64/portage/pym/portage/package/ebuild/fetch.py", line 582, in fetch vfs_stat = os.statvfs(mysettings["DISTDIR"]) OSError: [Errno 13] Permission denied: '/usr/portage/distfiles' Expected Results: emerge finds the files I have tried mounting with the context=system_u:object_r:portage_ebuild_t and rootcontext=system_u:object_r:portage_ebuild_t as per https://www.centos.org/docs/5/html/Deployment_Guide-en-US/sec-sel-admincontrol.html#rhlcommon-section-0097 but it still mounts as system_u:object_r:nfs_t
I have tried with this line both commented and uncommented. FEATURES="buildpkg webrsync-gpg usersandbox collision-protect userpriv userfetch fixlafiles news parallel-fetch unmerge-orphans unknown-features-warn usersync strict fixpackages fail-clean"
if the OS is giving you "permission denied", there's really nothing portage can do about it
this is a selinux policy issue, not portage. I asked to create a bugreport so that we can follow this up on the selinux policy development (part of gentoo hardened). Please reopen and reassign to selinux? can't do that myself currently yet
Preliminary tests show that we can go two ways here. Either we make a small adjustment to allow mounting with the context= option. In this case, the command to mount the NFS file system could be: ~# mount -t nfs -o context=system_u:object_r:portage_ebuild_t nfs_host:/nfs/portage /usr/portage The only additional "privilege" required here is allow mount_t portage_ebuild_t:filesystem relabelfrom; However, this does require that each specific location portage provides (/usr/portage as portage_ebuild_t and /usr/portage/distfiles/*src as portage_srcrepo_t) gets separate mount points as they require separate labels. What I will do is add a SELinux boolean "gentoo_portage_allow_nfs" which allows the appropriate domains to manage nfs_t files. You can then still see if you want to allow this (broad) privilege, or rather use a more detailed mount-mechanism as described earlier.
(In reply to comment #4) > Preliminary tests show that we can go two ways here. > > Either we make a small adjustment to allow mounting with the context= option. > In this case, the command to mount the NFS file system could be: > > ~# mount -t nfs -o context=system_u:object_r:portage_ebuild_t > nfs_host:/nfs/portage /usr/portage > > The only additional "privilege" required here is > allow mount_t portage_ebuild_t:filesystem relabelfrom; > > However, this does require that each specific location portage provides > (/usr/portage as portage_ebuild_t and /usr/portage/distfiles/*src as > portage_srcrepo_t) gets separate mount points as they require separate labels. > > What I will do is add a SELinux boolean "gentoo_portage_allow_nfs" which allows > the appropriate domains to manage nfs_t files. You can then still see if you > want to allow this (broad) privilege, or rather use a more detailed > mount-mechanism as described earlier. I personally prefer the mount based approach, as that seems more 'secure'.
True, but might be more challenging to manage. I'll take a look at why I need to allow _relabelfrom_ portage_ebuild_t rather than _relabelto_ portage_ebuild_t for the mount option to work...
The necessary fixes for this should now be available in the hardened-dev overlay
Is in portage tree (sec-policy/selinux-base-policy-2.20101213-r18)
And there was much rejoicing!
