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 ...
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2012-07-18 15:57:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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?
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
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.