Description of problem: SELinux is preventing /usr/bin/python2.7 from 'search' accesses on the directory /root. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that python2.7 should be allowed search access on the root 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:user_home_dir_t:s0 Target Objects /root [ dir ] Source firewalld Source Path /usr/bin/python2.7 Port <Unknown> Host (removed) Source RPM Packages python-2.7.5-3.fc20.x86_64 Target RPM Packages filesystem-3.2-17.fc20.x86_64 Policy RPM selinux-policy-3.12.1-68.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 3.11.0-0.rc3.git1.1.fc20.x86_64 #1 SMP Tue Jul 30 11:21:49 UTC 2013 x86_64 x86_64 Alert Count 7 First Seen 2013-07-30 07:35:23 COT Last Seen 2013-07-31 20:16:43 COT Local ID 8144ac68-060b-47d0-a007-5a08ef704a2e Raw Audit Messages type=AVC msg=audit(1375319803.881:17): avc: denied { search } for pid=288 comm="firewalld" name="root" dev="sda2" ino=524290 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir type=SYSCALL msg=audit(1375319803.881:17): arch=x86_64 syscall=stat success=no exit=ENOENT a0=11af310 a1=7ffffbbd3c80 a2=7ffffbbd3c80 a3=0 items=0 ppid=1 pid=288 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,user_home_dir_t,dir,search Additional info: reporter: libreport-2.1.6 hashmarkername: setroubleshoot kernel: 3.11.0-0.rc3.git1.1.fc20.x86_64 type: libreport
Why is your /root directory labeled user_home_dir_t? It should be labled admin_home_t. Does restorecon fix the label restorecon -R -v /root
Well, this is interesting, restorecon finally worked just but not as expected. Long story short: with the previous to last update to selinux-policy, the graphical subsystem started to hang and leave the system only accessible through the console, I used restorecon and boot time autorelabel several times with no results during the last couple of days; the only way was to disable selinux in the bootparams line. So I decided to set the system in permissive mode and see if that helped and it did. And found the bug that I submitted here. Now, operating in permissive mode I just ran restorecon -R -v on /root and the result is surprising: # restorecon -Rv root restorecon reset /root/.xauthnXoMxb context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:xauth_home_t:s0 Never saw that one before. Anyway, I'll reboot into enforcing mode and report back.
Well, I certainly did that comment in a rush, as I was leaving away from my desk. The thing is, the root directory was already properly labeled, right? I actually left running a full relabel to make sure and there were no errors after my return. I rebooted and still got a hung up system. Digging a bit more I found an error in gdm's system status (attached) that apparently is triggered by selinux policy 0:3.12.1-68 and looks like https://bugzilla.redhat.com/show_bug.cgi?id=968942 Then I noticed there were new updates available, including selinux policy 0:3.12.1-69, applied that and rebooted into a functioning gdm with enforcing mode. So, it is fixed as far as having a working system goes.
Created attachment 781722 [details] systemd's gdm.service status error when using selinux-policy-0:3.12.1-68 in enforcing mode.
fixed in selinux-policy-3.12.1-69.fc20