libreport version: 2.0.10 executable: /usr/bin/python2.7 hashmarkername: setroubleshoot kernel: 3.4.2-4.rt10.1.fc17.ccrma.x86_64.rt time: gio 28 giu 2012 15:59:22 CEST description: Text file, 4102 bytes
Created attachment 595028 [details] File: description
Did you try to add a label for this file? If you can remove this file then just remove it. If no, execute # chcon -t user_tmp_t /var/tmp/kdecache-root to fix this issue.
Sorry for the delay. As I have just made a clean FC17 install and subsequent package installs/updates, I would expect that all SELinux stuff is incrementally updated by the package system, aka YUM/Apper. Please confirm me whether this is the case or if I need to manually check the SELinux status after every single package install.
*** Bug 838703 has been marked as a duplicate of this bug. ***
*** Bug 838704 has been marked as a duplicate of this bug. ***
Could you try to remove /var/tmp/kdecache-root and then use KDE and execute # ls -dZ /var/tmp/kdecache-root
(In reply to comment #6) > Could you try to remove > > /var/tmp/kdecache-root > > and then use KDE and execute > > # ls -dZ /var/tmp/kdecache-root Hi Miroslav, I came accross the same problem after installing a fresh Fedora 17 system on my laptop. After I removed /var/tmp/kdecache-root directory, it did not get recreated. I tried to restart KDE a few times. I wander how it got created in the first place, since I've NEVER logged into KDE as 'root'.
Might have something to do with the livecd install process?
(In reply to comment #8) > Might have something to do with the livecd install process? I used a DVD, not the KDE livecd for this installation.
Could the kdm be doing it?
(In reply to comment #10) > Could the kdm be doing it? I suppose it could. But I restarted kdm a number of times after removing /var/tmp/kdecache-root directory, and it did not get recreated so far.
Ok if it comes back reopen bugzilla.
I have the same problem. The directory can be created simply by opening an app, like dolphin, as root. You do not have to "log in" as root for it to be created.
I think Michael B may be on to something - I started seeing this on my freshly installed F17 system (actually updated with preupgrade from an F16 Live USB, since that was what I had handy). I also get an SELinux warning for /tmpwatch complaining about the same directory. However, I believe I only saw it *after* running system-config-firewall from a root terminal session (or perhaps via sudo - I don't think it makes any real difference in this case). And looking at the ownership and security context for the offending directory $ ls -dZ /var/tmp/kdecache-root drwx------. root root system_u:object_r:unlabeled_t:s0 /var/tmp/kdecache-root My previous F17 system never exhibited this behaviour, but I also can't recall starting any GUI applications as root on that machine. I suspect this means this bug is currently assigned to the wrong component - the SELinux policy seems to be OK, but whatever is creating that /var/tmp/kdecache-root entry is doing something wrong. Contrast it with a similar entry created later and my user entry: # ls -dZ /var/tmp/kdecache-rooteVxxp0/ drwx------. root root system_u:object_r:xdm_tmp_t:s0 /var/tmp/kdecache-rooteVxxp0/ # ls -dZ /var/tmp/kdecache-ncoghlan/ drwx------. ncoghlan ncoghlan unconfined_u:object_r:user_tmp_t:s0 /var/tmp/kdecache-ncoghlan I was tinkering with running system-config-firewall as root to see if I could recreate the broken entry, but no luck (that's why I left the issue closed as "insufficient data" for the moment)
This is strange. I am not able to reproduce it. I am trying to use KDE Live USB to see what label is for /var/tmp/kdecache-root on F16 KDE system. But I am not able to trigger creating of this cache.
I would bet it is firstboot_tmp_t;
I never noticed this is Fedora 16, but with Fedora 17, SELinux is going off all of the time and I'd be happy to help do whatever I can to help end this annoyance. Is there any kind of debugging that a skilled non-programer like myself can do to help fix this?
Fixed in selinux-policy-3.10.0-142.fc17.noarch
(In reply to comment #18) > Fixed in selinux-policy-3.10.0-142.fc17.noarch Actually selinux-policy-3.10.0-143.fc17.noarch