type=AVC msg=audit(12/02/2012 11:11:54.188:248676) : avc: denied { write } for pid=5748 comm=semodule path=pipe:[740099] dev="pipefs" ino=740099 scontext=staff_u:unconfined_r:semanage_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file -Robin
Further, apparently from the same thing: ---- type=AVC msg=audit(12/02/2012 11:21:15.921:256149) : avc: denied { write } for pid=7301 comm=setfiles path=pipe:[743448] dev="pipefs" ino=743448 scontext=staff_u:unconfined_r:setfiles_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file type=AVC msg=audit(12/02/2012 11:21:15.921:256149) : avc: denied { write } for pid=7301 comm=setfiles path=pipe:[743448] dev="pipefs" ino=743448 scontext=staff_u:unconfined_r:setfiles_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file ---- type=AVC msg=audit(12/02/2012 11:21:16.105:256164) : avc: denied { write } for pid=7302 comm=load_policy path=pipe:[743448] dev="pipefs" ino=743448 scontext=staff_u:unconfined_r:load_policy_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file type=AVC msg=audit(12/02/2012 11:21:16.105:256164) : avc: denied { write } for pid=7302 comm=load_policy path=pipe:[743448] dev="pipefs" ino=743448 scontext=staff_u:unconfined_r:load_policy_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file The actual command is: /usr/sbin/semodule somelocalcrap.pp 2>&1 | less , for example. (not the actual module name :) -Robni
Erm, except with sudo. -Robin
Created attachment 656202 [details] My module install script.
Ahem. I'm very sorry, dgrift has made it clear to me that I did a crappy job in reporting this. Let's try again. There are two completely separate issues here that I stupidly assumed were one thing; please accept my apologies for wasting everyone's time. The original issue was that running puppet produces no output from semanage module failures. I run puppet as "sudo puppetd -tv", and it in turn runs my module script, which I've attached; specifically it runs "/usr/local/sbin/compile_selinux.sh myrealcorpus 2>&1" in this case, as a puppet "exec". The AVC for that, which is dontaudited, is: type=AVC msg=audit(12/02/2012 11:55:17.590:276671) : avc: denied { write } for pid=12021 comm=semodule path=/tmp/puppet20121202-11387-1e5f6dp dev="vda2" ino=265622 scontext=staff_u:unconfined_r:semanage_t:s0 tcontext=staff_u:object_r:user_tmp_t:s0 tclass=file Silently losing error output when puppet runs something is pretty annoying, because it's just like "lol nope". This also happens in my shell, but for totally different reasons, apparently. rlpowell@vrici> sudo -s /usr/local/sbin/compile_selinux.sh myrealcorpus 2>&1 | less make: Nothing to be done for `all'. rlpowell@vrici> The AVC is: type=AVC msg=audit(12/02/2012 12:01:40.189:277950) : avc: denied { write } for pid=12207 comm=semodule path=pipe:[758153] dev="pipefs" ino=758153 scontext=staff_u:unconfined_r:semanage_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file Contrariwise: rlpowell@vrici> sudo -s /usr/local/sbin/compile_selinux.sh myrealcorpus make: Nothing to be done for `all'. libsepol.sepol_context_from_string: malformed context "httpd_corpus_rw_content_t:s0" libsepol.sepol_context_from_string: could not construct context from string libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert httpd_corpus_rw_content_t:s0 to sid invalid context httpd_corpus_rw_content_t:s0 libsemanage.semanage_install_active: setfiles returned error code 1. /usr/sbin/semodule: Failed! My usual solution here, which is: sudo sh -c " /usr/local/sbin/compile_selinux.sh myrealcorpus 2>&1 | less" Works fine as always. I'm aware that this just sometimes happens with selinux, that pipes can't access each other and suchlike, but it seems like in this case potentially really useful error output is being silently lost, and it would be nice for it not to be. Fixing these AVCs opens up others; I have to go afk, but I'll post the whole list soon. I'm half expecting this to be closed NOTABUG; if so, I'd sure love a pointer to an explanation of *why* it's OK to silently drop this sort of thing, and how I can work around it in my scripting, and in particular in the puppet case. -Robin
Fixing the AVCs I just listed is enough to get the behaviour I want, so I dunno how important it is to mention the others, but from puppet I'm getting: type=AVC msg=audit(12/02/2012 12:42:34.227:284672) : avc: denied { write } for pid=14321 comm=load_policy path=/tmp/puppet20121202-13686-4vpnxe dev="vda2" ino=265622 scontext=staff_u:unconfined_r:load_policy_t:s0 tcontext=staff_u:object_r:user_tmp_t:s0 tclass=file type=AVC msg=audit(12/02/2012 12:42:35.283:284674) : avc: denied { write } for pid=14322 comm=setfiles path=/tmp/puppet20121202-13686-4vpnxe dev="vda2" ino=265622 scontext=staff_u:unconfined_r:setfiles_t:s0 tcontext=staff_u:object_r:user_tmp_t:s0 tclass=file The following also comes up in my puppet runs, which is obviously a different issue but still the same *sort* of thing: type=AVC msg=audit(12/02/2012 12:42:41.834:285059) : avc: denied { write } for pid=14326 comm=restorecon path=/tmp/puppet20121202-13686-1gqu4b2 dev="vda2" ino=265622 scontext=staff_u:unconfined_r:setfiles_t:s0 tcontext=staff_u:object_r:user_tmp_t:s0 tclass=file The AVCs for the shell are similar: type=AVC msg=audit(12/02/2012 12:49:54.589:287102) : avc: denied { write } for pid=14444 comm=load_policy path=pipe:[765831] dev="pipefs" ino=765831 scontext=staff_u:unconfined_r:load_policy_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file type=AVC msg=audit(12/02/2012 12:49:55.576:287104) : avc: denied { write } for pid=14445 comm=setfiles path=pipe:[765831] dev="pipefs" ino=765831 scontext=staff_u:unconfined_r:setfiles_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file That appears to be all of them. -Robin
Just checked a fix in for this in F18 policy 32c87a7b9c7873cdaaf3bf3e9e680feea9fb6db6 Basically allows all applications to use fifo_files inherited from user domains as well as write to tmp files inherited from user domains.
:D :D :D That's great, thank you so much! -Robin
Added to F17. commit 0efff3a8c0c603b9fd0578fbd0c3ad2d6efba0d8 Author: Dan Walsh <dwalsh> Date: Mon Dec 3 22:53:43 2012 -0500 Allow all application domains to use fifo_files passed in from userdomains
selinux-policy-3.10.0-165.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-165.fc17
Package selinux-policy-3.10.0-165.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-165.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-20544/selinux-policy-3.10.0-165.fc17 then log in and leave karma (feedback).
Package selinux-policy-3.10.0-166.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-166.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-20544/selinux-policy-3.10.0-166.fc17 then log in and leave karma (feedback).
selinux-policy-3.10.0-166.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.