>>> Emerging (1 of 1) sys-apps/portage-2.1.2 to / * portage-2.1.2.tar.bz2 MD5 ;-) ... [ ok ] * portage-2.1.2.tar.bz2 RMD160 ;-) ... [ ok ] * portage-2.1.2.tar.bz2 SHA1 ;-) ... [ ok ] * portage-2.1.2.tar.bz2 SHA256 ;-) ... [ ok ] * portage-2.1.2.tar.bz2 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking portage-2.1.2.tar.bz2 ;-) ... [ ok ] [Errno 13] Permission denied: tee -i -a /var/tmp/portage/sys-apps/portage-2.1.2/temp/build.log Jan 16 19:24:39 maya audit(1168975479.427:658): avc: denied { entrypoint } for pid=1031 comm="emerge" name="tee" dev=hda5 ino=116822 scontext=stephen:sysadm_r:portage_t.sandbox:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file With current policy, the only file types allowed as entrypoints to portage_t.sandbox are shells and portage executables. Either Portage needs to stop using `tee`, or the policy needs updating to allow any generic binary as an entrypoint.
(In reply to comment #0) > With current policy, the only file types allowed as entrypoints to > portage_t.sandbox are shells and portage executables. Either Portage needs to > stop using `tee`, or the policy needs updating to allow any generic binary as > an entrypoint. I can see why you'd want to minimize the entry points into that precious PORTAGE_TMPDIR. The log currently goes to ${T}/build.log when PORT_LOGDIR is unset but I suppose we can just send it to /dev/null when both PORT_LOGDIR is unset and sesandbox is enabled. In that case you won't get the QA that comes from grepping build.log but you can always set PORT_LOGDIR if you want that.
Maybe I misunderstood. Does this problem happen even when PORT_LOGDIR is set? If that's the case, I suppose we can spawn tee in the regular PORTAGE_T context and then switch to the PORTAGE_SANDBOX_T context just to spawn the shell. Shouldn't that work?
Created attachment 107250 [details, diff] spawn tee outside of the sesandbox context Hopefully this patch will solve the issue. Please test.
In svn r5690 I've committed the patch which causes tee to be spawned outside of the sesandbox domain and read from a pipe between two domains. @selinux: Stephen says the patch works except that the ebuild process in the sesandbox domain doesn't have permission to write to the pipe. Can the policy be updated so that pipe is allowed to work?
In svn r5718, I've fixed it so that logging with sesandbox will only occur when PORT_LOGDIR is explicitly enabled.
This has been released in 2.1.2-r1.
