Bug 990773 - SELinux is preventing /usr/bin/python2.7 from 'search' accesses on the directory /root.
SELinux is preventing /usr/bin/python2.7 from 'search' accesses on the direct...
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-07-31 21:23 EDT by P. A. López-Valencia
Modified: 2013-08-01 21:35 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-08-01 21:35:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
systemd's gdm.service status error when using selinux-policy-0:3.12.1-68 in enforcing mode. (1.32 KB, text/plain)
2013-08-01 15:12 EDT, P. A. López-Valencia
no flags Details

  None (edit)
Description P. A. López-Valencia 2013-07-31 21:23:32 EDT
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.
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
Comment 1 Daniel Walsh 2013-08-01 11:51:16 EDT
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
Comment 2 P. A. López-Valencia 2013-08-01 12:25:15 EDT
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.
Comment 3 P. A. López-Valencia 2013-08-01 15:10:48 EDT
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.
Comment 4 P. A. López-Valencia 2013-08-01 15:12:40 EDT
Created attachment 781722 [details]
systemd's gdm.service status error when using selinux-policy-0:3.12.1-68 in enforcing mode.
Comment 5 Daniel Walsh 2013-08-01 21:35:19 EDT
fixed in selinux-policy-3.12.1-69.fc20

Note You need to log in before you can comment on or make changes to this bug.