SELinux is preventing /usr/bin/systemd-tmpfiles from getattr access on the directory /var/tmp/kdecache-root.
***** Plugin catchall_labels (83.8 confidence) suggests ********************
If you want to allow systemd-tmpfiles to have getattr access on the kdecache-root directory Then you need to change the label on /var/tmp/kdecache-root Do # semanage fcontext -a -t FILE_TYPE '/var/tmp/kdecache-root' 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 '/var/tmp/kdecache-root'
***** Plugin catchall (17.1 confidence) suggests ***************************
If you believe that systemd-tmpfiles should be allowed getattr access on the kdecache-root 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 /var/tmp/kdecache-root [ dir ] Source systemd-tmpfile Source Path /usr/bin/systemd-tmpfiles Port <Unknown> Host yuxict Source RPM Packages systemd-44-17.fc17.i686 Target RPM Packages Policy RPM selinux-policy-3.10.0-134.fc17.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name yuxict Platform Linux yuxict 3.4.4-3.fc17.i686 #1 SMP Tue Jun 26 21:32:03 UTC 2012 i686 i686 Alert Count 3 First Seen Wed 04 Jul 2012 04:28:34 PM CST Last Seen Wed 04 Jul 2012 04:28:35 PM CST Local ID 70ac4e23-d403-4920-b306-692db38f4d6e
Raw Audit Messages type=AVC msg=audit(1341390515.119:58): avc: denied { getattr } for pid=1217 comm="systemd-tmpfile" path="/var/tmp/kdecache- root" dev="dm-1" ino=262165 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
type=SYSCALL msg=audit(1341390515.119:58): arch=i386 syscall=fstatat64 success=no exit=EACCES a0=4 a1=9fef1bb a2=bfde6c40 a3=100 items=0 ppid=1 pid=1217 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
hejian19870919 wrote:
SELinux is preventing /usr/bin/systemd-tmpfiles from getattr access on the directory /var/tmp/kdecache-root.
This sounds like either a bug in selinux-policy or a labeling issue on your system (or both). Please check whether there's already a bug filed against selinux-policy for this on bugzilla.redhat.com, and if not, file one.
Kevin Kofler
Subject: Re: SELinux is preventing /usr/bin/systemd-tmpfiles from getattr access on the directory /var/tmp/kdecache-root.
hejian19870919 wrote: SELinux is preventing /usr/bin/systemd-tmpfiles from getattr access on the directory /var/tmp/kdecache-root.
This sounds like either a bug in selinux-policy or a labeling issue on your system (or both). Please check whether there's already a bug filed against selinux-policy for this on bugzilla.redhat.com, and if not, file one.
Kevin Kofler
See if comment #2 helps. If not add your own comment:
https://bugzilla.redhat.com/show_bug.cgi?id=836262 _______________________________________________ kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
On 07/15/2012 07:50 PM, Kevin Kofler wrote:
hejian19870919 wrote:
SELinux is preventing /usr/bin/systemd-tmpfiles from getattr access on the directory /var/tmp/kdecache-root.
Hi,
I'm having this problem too. I'd be interested in following the progress of this bug. Can you let me/us know what the bug number is so I can follow it?
Thanks, Norman
On Wednesday, July 04, 2012 17:34:06 hejian19870919@163.com wrote:
SELinux is preventing /usr/bin/systemd-tmpfiles from getattr access on the directory /var/tmp/kdecache-root.
I saw this, too. I waited for an selinux update and it persisted after that. Finally, I actually read the message and wondered why I would ever have such a directory. I would never attempt to start KDE as the root user. I knew I didn't do that. I looked at the date on this directory and it matched the date I installed (fresh) F17. I haven't got a clue as to why it was created. I just deleted it and then started looking elsewhere. I see that a ~root/.kde directory and a ~root/.config directory exists. WTF? I deleted those, too. (They were also time-stamped with my install date.)
I don't know how the install went so wrong, but it's gone now.
This is from my shell history:
sudo restorecon /var/tmp/kdecache-root
That didn't do it. Later I did this:
sudo rmdir /var/tmp/kdecache-root sudo rm -rf /var/tmp/kdecache-rootGr0zAx sudo rm -rf /root/.kde /root/.config
Subject: Re: SELinux is preventing /usr/bin/systemd-tmpfiles from getattr access on the directory /var/tmp/kdecache-root.
On Wednesday, July 04, 2012 17:34:06 hejian19870919@163.com wrote:
SELinux is preventing /usr/bin/systemd-tmpfiles from getattr access on the directory /var/tmp/kdecache-root.
I saw this, too. I waited for an selinux update and it persisted after that. Finally, I actually read the message and wondered why I would ever have such a directory. I would never attempt to start KDE as the root user. I knew I didn't do that. I looked at the date on this directory and it matched the date I installed (fresh) F17. I haven't got a clue as to why it was created. I just deleted it and then started looking elsewhere. I see that a ~root/.kde directory and a ~root/.config directory exists. WTF? I deleted those, too. (They were also time-stamped with my install date.)
I don't know how the install went so wrong, but it's gone now.
This is from my shell history:
sudo restorecon /var/tmp/kdecache-root
That didn't do it. Later I did this:
sudo rmdir /var/tmp/kdecache-root sudo rm -rf /var/tmp/kdecache-rootGr0zAx sudo rm -rf /root/.kde /root/.config
-- Garry T. Williams
I also had a problem with .kde in root earlier in my F17 adventure. I removed the .kde folder in root and have had no problems with it since.
The solution was given by Dan Walsh in comment 15 of this Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=829850
According to Dan, it was a bug in KDE.
_______________________________________________ kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
goineasy9@aol.com wrote:
I also had a problem with .kde in root earlier in my F17 adventure. I removed the .kde folder in root and have had no problems with it since.
The solution was given by Dan Walsh in comment 15 of this Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=829850
According to Dan, it was a bug in KDE.
That's a completely different bug, it's about a /.kde folder in the root of the file system hierarchy (NOT in root's home directory), which is indeed a KDE bug (/root/.kde is where it SHOULD be).
Kevin Kofler
-----Original Message-----
From: Kevin Kofler kevin.kofler@chello.at To: kde kde@lists.fedoraproject.org Sent: Thu, Aug 2, 2012 8:40 pm Subject: Re: SELinux is preventing /usr/bin/systemd-tmpfiles from getattr access on the directory /var/tmp/kdecache-root.
goineasy9@aol.com wrote:
I also had a problem with .kde in root earlier in my F17 adventure. I removed the .kde folder in root and have had no problems with it since.
The solution was given by Dan Walsh in comment 15 of this Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=829850
According to Dan, it was a bug in KDE.
That's a completely different bug, it's about a /.kde folder in the root of the file system hierarchy (NOT in root's home directory), which is indeed a KDE bug (/root/.kde is where it SHOULD be).
Kevin Kofler
Thanks for pointing that out, I didn't realize that earlier. Then again, the programmer who wrote the code with the bug, made the same mistake I did. So I feel I'm in good company. :)
Tom _______________________________________________ kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
Garry T. Williams wrote:
Finally, I actually read the message and wondered why I would ever have such a directory. I would never attempt to start KDE as the root user. I knew I didn't do that.
Running anything using the kdelibs as root may create some or all of those directories, this includes: * KDM (maybe) * anything run through kdesu (even internally) * anything run through KAuth internally
KDE is not just the full workspace.
Kevin Kofler
On Friday, August 03, 2012 02:37:01 Kevin Kofler wrote:
Garry T. Williams wrote:
Finally, I actually read the message and wondered why I would ever have such a directory. I would never attempt to start KDE as the root user. I knew I didn't do that.
Running anything using the kdelibs as root may create some or all of those directories, this includes:
- KDM (maybe)
- anything run through kdesu (even internally)
- anything run through KAuth internally
KDE is not just the full workspace.
I tried searching through my shell histories, but came up empty. Oh well. I may never know.