Description of problem: SELinux is preventing /usr/bin/python2.7 from 'write' accesses on the directory /tmp. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that python2.7 should be allowed write access on the tmp directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep firewalld /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:firewalld_t:s0 Target Context system_u:object_r:tmp_t:s0 Target Objects /tmp [ dir ] Source firewalld Source Path /usr/bin/python2.7 Port <Unknown> Host (removed) Source RPM Packages python-2.7.3-14.fc19.x86_64 Target RPM Packages filesystem-3.2-2.fc19.x86_64 Policy RPM selinux-policy-3.11.1-67.fc19.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.7.0-6.fc19.x86_64 #1 SMP Fri Dec 21 18:33:18 UTC 2012 x86_64 x86_64 Alert Count 75 First Seen 2012-12-23 20:34:06 PST Last Seen 2012-12-24 12:55:46 PST Local ID a37d98d1-7a54-418a-b3fe-6aa4dde00fa5 Raw Audit Messages type=AVC msg=audit(1356382546.544:291): avc: denied { write } for pid=416 comm="firewalld" name="/" dev="tmpfs" ino=1659 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=SYSCALL msg=audit(1356382546.544:291): arch=x86_64 syscall=access success=no exit=EACCES a0=7fffca7c2906 a1=2 a2=0 a3=0 items=0 ppid=1 pid=416 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=firewalld exe=/usr/bin/python2.7 subj=system_u:system_r:firewalld_t:s0 key=(null) Hash: firewalld,firewalld_t,tmp_t,dir,write audit2allow #============= firewalld_t ============== #!!!! The source type 'firewalld_t' can write to a 'dir' of the following types: # firewalld_var_run_t, firewalld_var_log_t, var_log_t, var_run_t, firewalld_etc_rw_t allow firewalld_t tmp_t:dir write; audit2allow -R #============= firewalld_t ============== #!!!! The source type 'firewalld_t' can write to a 'dir' of the following types: # firewalld_var_run_t, firewalld_var_log_t, var_log_t, var_run_t, firewalld_etc_rw_t allow firewalld_t tmp_t:dir write; Additional info: hashmarkername: setroubleshoot kernel: 3.7.0-6.fc19.x86_64 type: libreport
Why is firewalld trying to write to /tmp?
I have no idea. This is a fresh install of MATE + F18 upgraded to Rawhide.
Question was directed more at the firewalld team? Thomas I am actually seeing firewalld searching for a place to write on rawhide? allow firewalld_t binfmt_misc_fs_t:dir write; allow firewalld_t configfs_t:dir write; allow firewalld_t debugfs_t:dir write; allow firewalld_t device_t:dir write; allow firewalld_t firewalld_var_run_t:file execute; allow firewalld_t home_root_t:dir write; allow firewalld_t hugetlbfs_t:dir write; allow firewalld_t security_t:dir write; allow firewalld_t self:capability dac_override; allow firewalld_t tmp_t:dir write; allow firewalld_t tmpfs_t:dir write; allow firewalld_t var_lib_nfs_t:dir search; Can you just get it to create its content in /run/firewalld?
firewalld is not searching a place to write. It is using tempfile.mkstemp, but with a fixed prefix. Could it be related to it?
What path is it attempting to do this in? What file is it attempting to write? I just added a dontaudit for the file systems
The prefix is "/etc/firewalld/firewalld.conf."
Maybe the use of dir="/etc/firewalld" and prefix="firewalld.conf." will fix this. What do you think?
Maybe.
Waiting on bootup Package: (null) OS Release: Fedora release 19 (Rawhide)
Upgrade from F18 to F19 (Rawhide). Package: (null) OS Release: Fedora release 19 (Rawhide)
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
No longer experiencing this.