Bug 727977 - SELinux is preventing /bin/systemd-tmpfiles from 'read' accesses on the directory dump.
Summary: SELinux is preventing /bin/systemd-tmpfiles from 'read' accesses on the direc...
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 15
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
Whiteboard: setroubleshoot_trace_hash:6c618cd87ca...
Depends On:
TreeView+ depends on / blocked
Reported: 2011-08-03 20:19 UTC by Eduardo Habkost
Modified: 2011-08-04 19:13 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-08-04 19:13:18 UTC

Attachments (Terms of Use)

Description Eduardo Habkost 2011-08-03 20:19:03 UTC
SELinux is preventing /bin/systemd-tmpfiles from 'read' accesses on the directory dump.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that systemd-tmpfiles should be allowed read access on the dump 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 systemd-tmpfile /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:systemd_tmpfiles_t:s0
Target Context                unconfined_u:object_r:admin_home_t:s0
Target Objects                dump [ dir ]
Source                        systemd-tmpfile
Source Path                   /bin/systemd-tmpfiles
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           systemd-units-26-8.fc15
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.16-35.fc15
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed)
                              2.6.40-4.fc15.x86_64 #1 SMP Fri Jul 29 18:46:53
                              UTC 2011 x86_64 x86_64
Alert Count                   11
First Seen                    Mon 25 Jul 2011 04:42:21 AM BRT
Last Seen                     Wed 03 Aug 2011 05:17:32 PM BRT
Local ID                      3e7a225c-dad4-49c6-bebf-d45464d407a0

Raw Audit Messages
type=AVC msg=audit(1312402652.53:148): avc:  denied  { read } for  pid=7043 comm="systemd-tmpfile" name="dump" dev=dm-1 ino=3170322 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=dir

type=SYSCALL msg=audit(1312402652.53:148): arch=x86_64 syscall=openat success=yes exit=ENXIO a0=4 a1=254028b a2=b0800 a3=0 items=0 ppid=1 pid=7043 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=systemd-tmpfile exe=/bin/systemd-tmpfiles subj=system_u:system_r:systemd_tmpfiles_t:s0 key=(null)

Hash: systemd-tmpfile,systemd_tmpfiles_t,admin_home_t,dir,read


#============= systemd_tmpfiles_t ==============
allow systemd_tmpfiles_t admin_home_t:dir read;

audit2allow -R

#============= systemd_tmpfiles_t ==============
allow systemd_tmpfiles_t admin_home_t:dir read;

Comment 1 Daniel Walsh 2011-08-04 18:53:56 UTC
Where is the dump directory located?  In /root?  How did systemd_tmpfiles_t no to look there?

Comment 2 Eduardo Habkost 2011-08-04 19:13:18 UTC
I had no idea how it was triggered, I never touched any systemd configuration and I don't know why it is trying to access that directory, so I reported it supposing it was an unexpected denial due to some default configuration.

But now I noticed that some time ago I created a "dump" directory on /root and then moved it to /tmp, ending up with this:

drwxr-xr-x. root root unconfined_u:object_r:admin_home_t:s0 /tmp/dump

So it was my fault, sorry for the noise.

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