Bug 836719 - SELinux is preventing /usr/bin/systemd-tmpfiles from getattr access on pulse tmp dir
SELinux is preventing /usr/bin/systemd-tmpfiles from getattr access on pulse ...
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2012-06-30 07:13 EDT by Ian Malone
Modified: 2012-07-18 15:57 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-07-18 15:57:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ian Malone 2012-06-30 07:13:27 EDT
I suppose this is a systemd or pulseaudio bug as the file isn't being created with the correct context?
The suggested related bugs that seem to match, 694584 and 836434, are marked CLOSE CURRENTRELEASE for Fedora 15 in Apr-2011, so they've re-surfaced in this clean F17 install.

SELinux is preventing /usr/bin/systemd-tmpfiles from getattr access on the directory /tmp/pulse-PKdhtXMmr18n.

*****  Plugin catchall_labels (83.8 confidence) suggests  ********************

If you want to allow systemd-tmpfiles to have getattr access on the pulse-PKdhtXMmr18n directory
Then you need to change the label on /tmp/pulse-PKdhtXMmr18n
# semanage fcontext -a -t FILE_TYPE '/tmp/pulse-PKdhtXMmr18n'
where FILE_TYPE is one of the following: security_t, rpm_var_cache_t, faillog_t, systemd_tmpfiles_t, var_spool_t, httpd_cache_t, proc_net_t, var_log_t, var_lib_t, var_run_t, textrel_shlib_t, user_home_type, init_var_run_t, rpm_script_tmp_t, rpm_var_lib_t, file_type, winbind_var_run_t, security_t, httpd_sys_rw_content_t, file_context_t, etc_t, cert_t, default_t, home_root_t, rpm_log_t, var_t, var_log_t, var_run_t, sssd_public_t, abrt_var_run_t, selinux_config_t, likewise_var_lib_t, user_home_dir_t, default_context_t, sysctl_crypto_t, filesystem_type, device_t, locale_t, var_auth_t, var_lock_t, krb5_conf_t, etc_t, file_t, proc_t, man_t, sysfs_t, tmpfs_t, root_t, tmp_t, config_home_t, usr_t, var_t, cpu_online_t, lockfile, setrans_var_run_t, pidfile, tmpfile, var_lib_t, var_run_t, device_t, samba_var_t, sysctl_t, etc_t, abrt_t, bin_t, samba_etc_t, proc_t, avahi_var_run_t, lib_t, mnt_t, sysfs_t, nscd_var_run_t, nslcd_var_run_t, root_t, smbd_var_run_t, sssd_var_lib_t, tmp_t, usr_t, var_t, lost_found_t, net_conf_t, sandbox_file_t, cpu_online_t, krb5_host_rcache_t, var_t, var_t, var_run_t, var_run_t, nscd_var_run_t, pcscd_var_run_t. 
Then execute: 
restorecon -v '/tmp/pulse-PKdhtXMmr18n'

*****  Plugin catchall (17.1 confidence) suggests  ***************************

If you believe that systemd-tmpfiles should be allowed getattr access on the pulse-PKdhtXMmr18n 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                system_u:object_r:unlabeled_t:s0
Target Objects                /tmp/pulse-PKdhtXMmr18n [ dir ]
Source                        systemd-tmpfile
Source Path                   /usr/bin/systemd-tmpfiles
Port                          <Unknown>
Host                          prometheus
Source RPM Packages           systemd-44-14.fc17.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-134.fc17.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     prometheus
Platform                      Linux prometheus 3.3.4-5.fc17.x86_64 #1 SMP Mon
                              May 7 17:29:34 UTC 2012 x86_64 x86_64
Alert Count                   1
First Seen                    Sat 30 Jun 2012 11:59:23 BST
Last Seen                     Sat 30 Jun 2012 11:59:23 BST
Local ID                      bc4fa271-c8e1-4978-a978-9dea4e63876f

Raw Audit Messages
type=AVC msg=audit(1341053963.929:66): avc:  denied  { getattr } for  pid=1443 comm="systemd-tmpfile" path="/tmp/pulse-PKdhtXMmr18n" dev="sda8" ino=262170 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir

type=SYSCALL msg=audit(1341053963.929:66): arch=x86_64 syscall=newfstatat success=no exit=EACCES a0=4 a1=2620c93 a2=7fff0040cd30 a3=100 items=0 ppid=1 pid=1443 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=/usr/bin/systemd-tmpfiles subj=system_u:system_r:systemd_tmpfiles_t:s0 key=(null)

Hash: systemd-tmpfile,systemd_tmpfiles_t,unlabeled_t,dir,getattr

audit2allowunable to open /sys/fs/selinux/policy:  Permission denied

audit2allow -Runable to open /sys/fs/selinux/policy:  Permission denied
Comment 1 Michal Schmidt 2012-07-02 03:52:19 EDT
There should be no files marked unlabeled_t in the filesystem.
What do these commands show?:
ls -Zd /tmp/pulse*
ps Zx | grep pulse
Comment 2 Ian Malone 2012-07-03 15:33:46 EDT
$ ls -Zd /tmp/pulse*
drwx------. gdm gdm system_u:object_r:xdm_tmp_t:s0   /tmp/pulse-4WI5YacEGKbt
drwx------. ian ian unconfined_u:object_r:user_tmp_t:s0 /tmp/pulse-pOp3QUvbn8Y2

$ ps Zx | grep pulse
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 961 ? Sl   0:00 /usr/bin/pulseaudio --start

That can't be right? This was a clean install of F17 on 21/6 with just normal updates and no tweaking. I rebooted and forced a relabel before taking those results.
Comment 3 Michal Schmidt 2012-07-04 06:28:56 EDT
The labels in comment #2 are all correct.
I think you fixed the problem by the relabeling. I don't know how we can now find out what caused the bad labels in the first place.
Comment 4 Stanis Shramko 2012-07-16 13:57:39 EDT
I have the fresh install of FC17 and this bug. What should I do to provide the needed info?
Comment 5 Stanis Shramko 2012-07-16 13:58:54 EDT
[stanis@home ~] % ls -Zd /tmp/pulse*                                  [0:52:02]
drwx------. stanis stanis unconfined_u:object_r:user_tmp_t:s0 /tmp/pulse-fyYMPNxzyflr
drwx------. root   root   system_u:object_r:unlabeled_t:s0 /tmp/pulse-PKdhtXMmr18n
drwx------. gdm    gdm    system_u:object_r:xdm_tmp_t:s0   /tmp/pulse-tQBRlqXmkTFl
[stanis@home ~] % ps Zx | grep pulse                                  [0:58:17]
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 1264 ? S<l   2:14 /usr/bin/pulseaudio --start
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 3334 pts/0 S+   0:00 grep --color=auto pulse
[stanis@home ~] %                                                     [0:58:30]
Comment 6 Michal Schmidt 2012-07-17 07:33:51 EDT
(In reply to comment #5)
> [stanis@home ~] % ls -Zd /tmp/pulse*                                 
> [0:52:02]
> drwx------. stanis stanis unconfined_u:object_r:user_tmp_t:s0
> /tmp/pulse-fyYMPNxzyflr
> drwx------. root   root   system_u:object_r:unlabeled_t:s0
> /tmp/pulse-PKdhtXMmr18n
> drwx------. gdm    gdm    system_u:object_r:xdm_tmp_t:s0  
> /tmp/pulse-tQBRlqXmkTFl

The directories owned by 'stanis' and 'gdm' are OK. The directory owned by root is suspicious. Pulseaudio should not be run under root. I don't know what did it.
Perhaps you could look at the creation timestamp of the directory and then look at the logs from that time.
I don't know how it became unlabeled_t. Maybe it had a valid type earlier, but a policy update invalidated it.
Let's see if SELinux experts have any ideas. Reopening and reassigning to selinux-policy.
Comment 7 Daniel Walsh 2012-07-18 15:57:46 EDT
Just remove the directory.  I think we removed a label that was used for these files and it caused the label to become unlabeled_t.  

rm -rf /tmp/pulse-PKdhtXMmr18n

Should fix the problem.  Reopen if it happens again.

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