Bug 836434 - SELinux is preventing /usr/sbin/tmpwatch from 'getattr' accesses on the directory /tmp/pulse-PKdhtXMmr18n.
SELinux is preventing /usr/sbin/tmpwatch from 'getattr' accesses on the direc...
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
17
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
abrt_hash:a86deebec59e235431ad2e28ae7...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-29 01:39 EDT by frywalker
Modified: 2012-08-06 13:29 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-29 18:25:09 EDT
Type: ---
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 frywalker 2012-06-29 01:39:43 EDT
libreport version: 2.0.10
executable:     /usr/bin/python2.7
hashmarkername: setroubleshoot
kernel:         3.4.3-1.fc17.x86_64
time:           Fri 29 Jun 2012 07:39:14 AM CEST

description:
:SELinux is preventing /usr/sbin/tmpwatch from 'getattr' accesses on the directory /tmp/pulse-PKdhtXMmr18n.
:
:*****  Plugin catchall_labels (83.8 confidence) suggests  ********************
:
:If you want to allow tmpwatch 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: tmp_t, var_t, amavis_spool_t, user_home_dir_t, textrel_shlib_t, filesystem_type, device_t, locale_t, etc_t, file_t, proc_t, man_t, rpm_script_tmp_t, tmp_t, usr_t, var_t, winbind_var_run_t, security_t, etc_t, cert_t, default_t, tmpfile, rpm_log_t, var_t, var_log_t, cfengine_var_lib_t, var_run_t, sssd_public_t, abrt_var_run_t, var_run_t, sandbox_file_t, abrt_var_run_t, likewise_var_lib_t, sysctl_crypto_t, kismet_log_t, rpm_var_cache_t, krb5_conf_t, var_spool_t, httpd_cache_t, var_log_t, var_lib_t, user_home_type, cfengine_var_lib_t, setrans_var_run_t, file_type, httpd_sys_rw_content_t, var_lib_t, var_run_t, device_t, print_spool_t, samba_var_t, sysctl_t, etc_t, abrt_t, bin_t, samba_etc_t, proc_t, home_root_t, avahi_var_run_t, lib_t, mnt_t, sysfs_t, nscd_var_run_t, nslcd_var_run_t, tmpreaper_t, root_t, smbd_var_run_t, sssd_var_lib_t, tmp_t, usr_t, var_t, net_conf_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 tmpwatch 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 tmpwatch /var/log/audit/audit.log | audit2allow -M mypol
:# semodule -i mypol.pp
:
:Additional Information:
:Source Context                system_u:system_r:tmpreaper_t:s0-s0:c0.c1023
:Target Context                system_u:object_r:unlabeled_t:s0
:Target Objects                /tmp/pulse-PKdhtXMmr18n [ dir ]
:Source                        tmpwatch
:Source Path                   /usr/sbin/tmpwatch
:Port                          <Unknown>
:Host                          (removed)
:Source RPM Packages           tmpwatch-2.10.3-2.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                     (removed)
:Platform                      Linux beefy-miracle 3.4.3-1.fc17.x86_64 #1 SMP Mon
:                              Jun 18 19:53:17 UTC 2012 x86_64 x86_64
:Alert Count                   1
:First Seen                    Fri 29 Jun 2012 03:14:38 AM CEST
:Last Seen                     Fri 29 Jun 2012 03:14:38 AM CEST
:Local ID                      15232f64-e4ca-460f-a80a-ba168a00e7c5
:
:Raw Audit Messages
:type=AVC msg=audit(1340932478.127:1747): avc:  denied  { getattr } for  pid=28640 comm="tmpwatch" path="/tmp/pulse-PKdhtXMmr18n" dev="dm-2" ino=786441 scontext=system_u:system_r:tmpreaper_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
:
:
:type=SYSCALL msg=audit(1340932478.127:1747): arch=x86_64 syscall=lstat success=no exit=EACCES a0=19e755b a1=7fffb154e470 a2=7fffb154e470 a3=324237839d items=0 ppid=28637 pid=28640 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=111 comm=tmpwatch exe=/usr/sbin/tmpwatch subj=system_u:system_r:tmpreaper_t:s0-s0:c0.c1023 key=(null)
:
:Hash: tmpwatch,tmpreaper_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 Daniel Walsh 2012-06-29 18:25:09 EDT
This looks like you had some files with labels that the kernel no longer understands.

rm -rf /tmp/pulse-PKdhtXMmr18

If you believe you no longer need these.

chcon -t user_tmp_t /tmp/pulse-PKdhtXMmr18 -r

If you want them around for a while, I have no idea how this content got there.
Comment 2 James 2012-07-02 10:48:56 EDT
I see this message as well about once a day. Fedora 17 + XFCE.
Comment 3 Daniel Walsh 2012-07-18 16:23:16 EDT
What does this output

getfattr -n security.selinux /tmp/pulse-*
Comment 4 Michael B. 2012-08-05 13:16:42 EDT
I'm having a similar problem, except that it's happening on the directory kdecache-root. I tried using the automatic bug reporting tool to make a new bug report, but it kept telling me it was a dupe of this one. It happens all the time on both of my Fedora 17 + KDE computers. If this is indeed the same problem, I'd be happy to help you get the info you need to investigate it.
Comment 5 Daniel Walsh 2012-08-06 10:40:35 EDT
Michael just delete the directory you should not see this again.
Comment 6 Michael B. 2012-08-06 11:32:25 EDT
I already did on my main computer. I was more concerned about it affecting large numbers of Fedora KDE users.
Comment 7 Daniel Walsh 2012-08-06 13:29:54 EDT
This is a one time thing, which should be fixed by the latest policy update.  Basically what happened is we removed a label for content created by firstboot during install.  This content in /tmp became unlabeled_t and tmpwatch was not able to look at it.  The latest policy has an "Alias" for the label we removed so if a users is fully up2date, this problem will cease to happen.

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