Red Hat Bugzilla – Bug 836719
SELinux is preventing /usr/bin/systemd-tmpfiles from getattr access on pulse tmp dir
Last modified: 2012-07-18 15:57:46 EDT
I suppose this is a systemd or pulseaudio bug as the file isn't being created with the correct context? systemd-44-14.fc17.x86_64 pulseaudio-1.1-9.fc17.x86_64 selinux-policy-3.10.0-134.fc17.noarch 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 Do # 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. Do 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
There should be no files marked unlabeled_t in the filesystem. What do these commands show?: ls -Zd /tmp/pulse* ps Zx | grep pulse
$ 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.
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.
I have the fresh install of FC17 and this bug. What should I do to provide the needed info?
[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]
(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.
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.