Summary: SELinux is preventing /sbin/setfiles access to a leaked /tmp/tmp7Cm72z file descriptor. Detailed Description: [restorecon has a permissive type (setfiles_t). This access was not denied.] SELinux denied access requested by the restorecon command. It looks like this is either a leaked descriptor or restorecon output was redirected to a file it is not allowed to access. Leaks usually can be ignored since SELinux is just closing the leak and reporting the error. The application does not use the descriptor, so it will run properly. If this is a redirection, you will not get output in the /tmp/tmp7Cm72z. You should generate a bugzilla on selinux-policy, and it will get routed to the appropriate package. You can safely ignore this avc. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Additional Information: Source Context system_u:system_r:setfiles_t:s0-s0:c0.c1023 Target Context system_u:object_r:initrc_tmp_t:s0 Target Objects /tmp/tmp7Cm72z [ file ] Source restorecon Source Path /sbin/setfiles Port <Unknown> Host (removed) Source RPM Packages policycoreutils-2.0.82-13.fc13 Target RPM Packages Policy RPM selinux-policy-3.7.19-10.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name leaks Host Name (removed) Platform Linux (removed) 2.6.33.3-85.fc13.i686.PAE #1 SMP Thu May 6 18:27:11 UTC 2010 i686 i686 Alert Count 2 First Seen Wed 07 Jul 2010 10:41:41 PM BST Last Seen Wed 07 Jul 2010 10:41:42 PM BST Local ID 5b9e8a98-58f8-4c6d-9111-c223e0cc1022 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1278538902.419:32): avc: denied { read append } for pid=3434 comm="restorecon" path="/tmp/tmp7Cm72z" dev=sda2 ino=71432 scontext=system_u:system_r:setfiles_t:s0-s0:c0.c1023 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file node=(removed) type=SYSCALL msg=audit(1278538902.419:32): arch=40000003 syscall=11 success=yes exit=0 a0=861d3e0 a1=86196e0 a2=8619468 a3=86196e0 items=0 ppid=3199 pid=3434 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="restorecon" exe="/sbin/setfiles" subj=system_u:system_r:setfiles_t:s0-s0:c0.c1023 key=(null) Hash String generated from leaks,restorecon,setfiles_t,initrc_tmp_t,file,read,append audit2allow suggests: #============= setfiles_t ============== allow setfiles_t initrc_tmp_t:file { read append };
What is running as initrc_t? # ps -eZ | grep initrc_t Also please update selinux-policy. yum update selinux-policy-targeted
(In reply to comment #1) > What is running as initrc_t? > > # ps -eZ | grep initrc_t > > > Also please update selinux-policy. > > yum update selinux-policy-targeted I am unsure as to what is running as initrc-t And ps etc. doesn't seem to provide an answer. This is with the latest selinux-policy-targeted update.
I encountered this AVC denial while installing packages with PackageKit.
Thanks for info. chcon -t rpm_exec_t /usr/libexec/packagekitd Will fix these issues for now.
*** Bug 610314 has been marked as a duplicate of this bug. ***
*** Bug 612376 has been marked as a duplicate of this bug. ***
*** Bug 613304 has been marked as a duplicate of this bug. ***
*** Bug 613492 has been marked as a duplicate of this bug. ***
*** Bug 613240 has been marked as a duplicate of this bug. ***
*** Bug 613280 has been marked as a duplicate of this bug. ***
Miroslav: Is this the same as bug 610521 and bug 610527 and bug 607399? Where is the problem and when was it introduced? Is it PackageKit or selinux-policy? There has been more than 100 reports of this kind of problems. It could be nice to get a fix ASAP.
https://bugzilla.redhat.com/show_bug.cgi?id=612327 >Is it PackageKit or selinux-policy? For me it is signed with SELinux. I have a picture of de problems url=http://www.evarie.dse.nl/fedora13/SELinux.Troubleshoot_error-log.jpg In this picture, you can see that the error is coming form a temporary file at /tmp/tmpqddjbt And the error was came after my first fresh installed Fedora 13 on my Dell Optiplex GX260 with a internet connection. The picture has the text: SELinux blocked entry till a lekaged file write. SELinux belet /usr/sbin/semodule toegang tot een gelekte /tmp/tmpqddjbt bestands beschrijving. /sbin/setfiles/ /tmp/tmpqddjbt /usr/sbin/tzdata-update /tmp/tmpqddjbt /usr/sbin/groupadd /tmp/tmpqddjbt
Fixed in selinux-policy-3.7.19-36.fc13
*** Bug 607399 has been marked as a duplicate of this bug. ***
When i tried to post this bug report from the automatic reporting process on my Fedora13 it automatically linked me to https://bugzilla.redhat.com/show_bug.cgi?id=610314 which is a closed duplicate of this bug-report. Also despite having a login for bugzilla for Ubuntu i had to setup a separate account for fedora. Is this on a family basis or do i need a separate account for each distro i use? Regards from Tom :)
selinux-policy-3.7.19-37.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/selinux-policy-3.7.19-37.fc13
Tom, this is bugzilla.redhat.com Which is very different then the Ubunto bug reporting system.
Hi, thanks :0 So this covers CentOS, Scientific Linux, Fedora and others too? or is it restricted to offical variants, so just the list and no others? Regards from Tom :)
You can report any bugs that comes from a fedora package or any OS based on fedora packages.
I had this problem occur immediately after a fresh install of a Fedora 13 VM, virtualized in VirtualBox w/ Linux host. I was updating the VM, then got the the same problem, noting it is a duplicate of Bug 610314. + Guest Information: Fedora release 13 (Goddard) + Host Information: lsb_release -rd Description: Ubuntu 10.04 LTS Release: 10.04 + VirtualBox Information: apt-cache policy virtualbox-3.2 virtualbox-3.2: Installed: 3.2.6-63112~Ubuntu~Lucid Candidate: 3.2.6-63112~Ubuntu~Lucid Version table: *** 3.2.6-63112~Ubuntu~Lucid 0 100 /var/lib/dpkg/status + Full Error Output: Summary: SELinux is preventing /usr/sbin/tzdata-update access to a leaked /tmp/tmpf_y8el file descriptor. Detailed Description: [tzdata-update has a permissive type (tzdata_t). This access was not denied.] SELinux denied access requested by the tzdata-update command. It looks like this is either a leaked descriptor or tzdata-update output was redirected to a file it is not allowed to access. Leaks usually can be ignored since SELinux is just closing the leak and reporting the error. The application does not use the descriptor, so it will run properly. If this is a redirection, you will not get output in the /tmp/tmpf_y8el. You should generate a bugzilla on selinux-policy, and it will get routed to the appropriate package. You can safely ignore this avc. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Additional Information: Source Context system_u:system_r:tzdata_t:s0-s0:c0.c1023 Target Context system_u:object_r:initrc_tmp_t:s0 Target Objects /tmp/tmpf_y8el [ file ] Source tzdata-update Source Path /usr/sbin/tzdata-update Port <Unknown> Host (removed) Source RPM Packages glibc-common-2.12-1 Target RPM Packages Policy RPM selinux-policy-3.7.19-10.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name leaks Host Name (removed) Platform Linux localhost.localdomain 2.6.33.3-85.fc13.i686 #1 SMP Thu May 6 18:44:12 UTC 2010 i686 i686 Alert Count 6 First Seen Mon 09 Aug 2010 01:16:57 AM EDT Last Seen Mon 09 Aug 2010 01:17:33 AM EDT Local ID 94059856-2e11-47e1-9897-0e0a0e1952dc Line Numbers Raw Audit Messages node=localhost.localdomain type=AVC msg=audit(1281331053.943:18749): avc: denied { read append } for pid=1945 comm="tzdata-update" path="/tmp/tmpf_y8el" dev=dm-0 ino=39245 scontext=system_u:system_r:tzdata_t:s0-s0:c0.c1023 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file node=localhost.localdomain type=AVC msg=audit(1281331053.943:18749): avc: denied { read append } for pid=1945 comm="tzdata-update" path="/tmp/tmpf_y8el" dev=dm-0 ino=39245 scontext=system_u:system_r:tzdata_t:s0-s0:c0.c1023 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file node=localhost.localdomain type=SYSCALL msg=audit(1281331053.943:18749): arch=40000003 syscall=11 success=yes exit=0 a0=ed35f60 a1=ed35f38 a2=ed25d10 a3=0 items=0 ppid=1894 pid=1945 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="tzdata-update" exe="/usr/sbin/tzdata-update" subj=system_u:system_r:tzdata_t:s0-s0:c0.c1023 key=(null)
Summary: SELinux is preventing /usr/sbin/semodule access to a leaked /tmp/tmpcP1IgR file descriptor. Detailed Description: [semodule has a permissive type (semanage_t). This access was not denied.] SELinux denied access requested by the semodule command. It looks like this is either a leaked descriptor or semodule output was redirected to a file it is not allowed to access. Leaks usually can be ignored since SELinux is just closing the leak and reporting the error. The application does not use the descriptor, so it will run properly. If this is a redirection, you will not get output in the /tmp/tmpcP1IgR. You should generate a bugzilla on selinux-policy, and it will get routed to the appropriate package. You can safely ignore this avc. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Additional Information: Source Context system_u:system_r:semanage_t:s0-s0:c0.c1023 Target Context system_u:object_r:initrc_tmp_t:s0 Target Objects /tmp/tmpcP1IgR [ file ] Source semodule Source Path /usr/sbin/semodule Port <Unknown> Host (removed) Source RPM Packages policycoreutils-2.0.82-31.fc13 Target RPM Packages Policy RPM selinux-policy-3.7.19-41.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name leaks Host Name (removed) Platform Linux xxxxx.xxxx 2.6.33.6-147.2.4.fc13.i686.PAE #1 SMP Fri Jul 23 17:21:06 UTC 2010 i686 i686 Alert Count 3 First Seen Tue 10 Aug 2010 09:53:25 PM PDT Last Seen Tue 10 Aug 2010 09:53:26 PM PDT Local ID a2464711-0ba8-4c11-bebb-0b5baa6a1842 Line Numbers Raw Audit Messages node=xxxxx.xxxx type=AVC msg=audit(1281502406.732:27149): avc: denied { append } for pid=3422 comm="semodule" path="/tmp/tmpcP1IgR" dev=dm-0 ino=261705 scontext=system_u:system_r:semanage_t:s0-s0:c0.c1023 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file node=xxxxx.xxxx type=AVC msg=audit(1281502406.732:27149): avc: denied { append } for pid=3422 comm="semodule" path="/tmp/tmpcP1IgR" dev=dm-0 ino=261705 scontext=system_u:system_r:semanage_t:s0-s0:c0.c1023 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file node=xxxxx.xxxx type=SYSCALL msg=audit(1281502406.732:27149): arch=40000003 syscall=11 success=yes exit=0 a0=961b728 a1=961b778 a2=9617458 a3=961b778 items=0 ppid=3421 pid=3422 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="semodule" exe="/usr/sbin/semodule" subj=system_u:system_r:semanage_t:s0-s0:c0.c1023 key=(null)
Summary: SELinux is preventing /sbin/setfiles access to a leaked /tmp/tmpcP1IgR file descriptor. Detailed Description: [restorecon has a permissive type (setfiles_t). This access was not denied.] SELinux denied access requested by the restorecon command. It looks like this is either a leaked descriptor or restorecon output was redirected to a file it is not allowed to access. Leaks usually can be ignored since SELinux is just closing the leak and reporting the error. The application does not use the descriptor, so it will run properly. If this is a redirection, you will not get output in the /tmp/tmpcP1IgR. You should generate a bugzilla on selinux-policy, and it will get routed to the appropriate package. You can safely ignore this avc. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Additional Information: Source Context system_u:system_r:setfiles_t:s0-s0:c0.c1023 Target Context system_u:object_r:initrc_tmp_t:s0 Target Objects /tmp/tmpcP1IgR [ file ] Source restorecon Source Path /sbin/setfiles Port <Unknown> Host (removed) Source RPM Packages policycoreutils-2.0.82-31.fc13 Target RPM Packages Policy RPM selinux-policy-3.7.19-41.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name leaks Host Name (removed) Platform Linux (removed) 2.6.33.6-147.2.4.fc13.i686.PAE #1 SMP Fri Jul 23 17:21:06 UTC 2010 i686 i686 Alert Count 3 First Seen Tue 10 Aug 2010 09:54:34 PM PDT Last Seen Tue 10 Aug 2010 09:54:34 PM PDT Local ID 18c79aab-aa01-46eb-8257-4f81ba15d28a Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1281502474.917:27152): avc: denied { read append } for pid=3498 comm="restorecon" path="/tmp/tmpcP1IgR" dev=dm-0 ino=261705 scontext=system_u:system_r:setfiles_t:s0-s0:c0.c1023 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file node=(removed) type=SYSCALL msg=audit(1281502474.917:27152): arch=40000003 syscall=11 success=yes exit=0 a0=961ac70 a1=96176d0 a2=9617458 a3=96176d0 items=0 ppid=3416 pid=3498 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="restorecon" exe="/sbin/setfiles" subj=system_u:system_r:setfiles_t:s0-s0:c0.c1023 key=(null)
Make sure /usr/libexec/packagekitd is labeled correctly restrecon -R -v /usr/libexec/packagekitd ls -lZ /usr/libexec/packagekitd -rwxr-xr-x. root root system_u:object_r:rpm_exec_t:s0 /usr/libexec/packagekitd
This issue has been fixed for more than two weeks, right? The reports that continues to pop in are from un-updated machines? So this issue should be CLOSED instead of ON_QA?
Never seen this bug again. It seems fixed for me.
My system should be up to date (System > Administration > Software Update says I'm up to date) and I just encountered this again. :\
As requested: [bamccaig@krypton ~]$ rpm -q selinux-policy selinux-policy-targeted setroubleshoot selinux-policy-3.7.19-44.fc13.noarch selinux-policy-targeted-3.7.19-44.fc13.noarch setroubleshoot-2.2.91-1.fc13.i686 [bamccaig@krypton ~]$ ps -eZ | grep initrc_t [bamccaig@krypton ~]$ ps -eZ | grep packagekitd system_u:system_r:rpm_t:s0-s0:c0.c1023 12110 ? 00:00:00 packagekitd [bamccaig@krypton ~]$ ls -lZ /usr/libexec/packagekitd -rwxr-xr-x. root root system_u:object_r:rpm_exec_t:s0 /usr/libexec/packagekitd [bamccaig@krypton ~]$
What is "resolved as CURRENTRELEASE?" I can ASSURE you that is has NOT been resolved. Does this mean that a patch is being prepared, or that you think it has been resolved in the current release? Please Clarify. Thank you.
This means that packagekitd being moved to a different directory and running with the wrong label has been fixed in the Current Release. If you are still seeing something similar and your labeling is correct, then I think you have a different bug.
this is still a problem for systems that are up to date. what info do I need to submit ? the reporter keeps marking it as a dupe of this bug, but I assure you I am updated as much as I can and am still seeing this bug at every boot.
I concur. This is a persistent problem, unless... By "Current Release" do you mean the fix has been pushed only to the updates-testing repo, but NOT to the updates repo? I ask because I do not have updates-testing enabled, and wonder if enabling it and running an update would fix the issue for me (and others).
What process is running as initrc_t? ps -eZ | grep initrc_t Looks like a program that is doing installs. Processes running as initrc_t created files in /tmp labeled initrc_tmp_t. And yum programs pass stdout as with getattr append access. Which is causing any confined applications that run in the post install to need this access. We had a bug in selinux-policy when packagekitd changed it location. This caused bugs that looked like this to happen. It has been fixed. I am guessing you are having a similar problem. But we need to know what is running as initrc_t.
fastest one will be off a virtual machine I have installed on this laptop. going to be days before I can touch a machine where F13 is install as something other than guest. [Mark@localhost ~]$ ps -eZ | grep initrc_t system_u:system_r:initrc_t:s0 1515 ? 00:00:01 VBoxService what else can I provide?
I would guess lsof /tmp/TEMPFILE while it is running to see what process created it.
I don't know how todo that seeing as it is gone by the time I can get to it at boot.
SELinux is preventing /usr/sbin/semodule access to a leaked /tmp/tmpUdXh9R file descriptor. Detailed Description: [semodule has a permissive type (semanage_t). This access was not denied.] SELinux denied access requested by the semodule command. It looks like this is either a leaked descriptor or semodule output was redirected to a file it is not allowed to access. Leaks usually can be ignored since SELinux is just closing the leak and reporting the error. The application does not use the descriptor, so it will run properly. If this is a redirection, you will not get output in the /tmp/tmpUdXh9R. You should generate a bugzilla on selinux-policy, and it will get routed to the appropriate package. You can safely ignore this avc. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Additional Information: Source Context system_u:system_r:semanage_t:s0-s0:c0.c1023 Target Context system_u:object_r:initrc_tmp_t:s0 Target Objects /tmp/tmpUdXh9R [ file ] Source semodule Source Path /usr/sbin/semodule Port <Unknown> Host localhost.MASdomain Source RPM Packages policycoreutils-2.0.82-13.fc13 Target RPM Packages Policy RPM selinux-policy-3.7.19-10.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name leaks Host Name localhost.MASdomain Platform Linux localhost.MASdomain 2.6.33.3-85.fc13.i686 #1 SMP Thu May 6 18:44:12 UTC 2010 i686 i686 Alert Count 3 First Seen Mon 09 Aug 2010 12:18:30 PM MDT Last Seen Mon 09 Aug 2010 12:19:13 PM MDT Local ID 16fa47e7-1734-4756-a255-6ee32026217d Line Numbers Raw Audit Messages node=localhost.MASdomain type=AVC msg=audit(1281377953.676:45): avc: denied { append } for pid=7541 comm="semodule" path="/tmp/tmpUdXh9R" dev=dm-1 ino=61676 scontext=system_u:system_r:semanage_t:s0-s0:c0.c1023 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file node=localhost.MASdomain type=AVC msg=audit(1281377953.676:45): avc: denied { append } for pid=7541 comm="semodule" path="/tmp/tmpUdXh9R" dev=dm-1 ino=61676 scontext=system_u:system_r:semanage_t:s0-s0:c0.c1023 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file node=localhost.MASdomain type=SYSCALL msg=audit(1281377953.676:45): arch=40000003 syscall=11 success=yes exit=0 a0=9f5e760 a1=9f5e7b0 a2=9f5a490 a3=9f5e7b0 items=0 ppid=7540 pid=7541 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="semodule" exe="/usr/sbin/semodule" subj=system_u:system_r:semanage_t:s0-s0:c0.c1023 key=(null) [Mark@localhost ~]$ lsof /tmp/tmpUdXh9R lsof: status error on /tmp/tmpUdXh9R: No such file or directory lsof 4.83 latest revision: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/ latest FAQ: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ latest man page: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_man usage: [-?abhlnNoOPRtUvVX] [+|-c c] [+|-d s] [+D D] [+|-f[gG]] [-F [f]] [-g [s]] [-i [i]] [+|-L [l]] [+m [m]] [+|-M] [-o [o]] [-p s] [+|-r [t]] [-s [p:s]] [-S [t]] [-T [t]] [-u s] [+|-w] [-x [fl]] [-Z [Z]] [--] [names] Use the ``-h'' option to get more help information. [root@localhost ~]# yum update -y ; yum upgrade -y Loaded plugins: presto, refresh-packagekit Setting up Update Process No Packages marked for Update Loaded plugins: presto, refresh-packagekit Setting up Upgrade Process No Packages marked for Update
According the the alert you just attached, this has not happened since August 9?
mark 2010-08-23 12:41:43 EDT somebody has done something because this bug is not troubling me any more
Yes a fix went out a while ago.
I delete the notification every time at boot and every boot it comes back at the next boot. am I supposed to check the ignore alert box?
That confuses me too. I end up deleting them all (after first reporting them).
i was just deleteing them at every boot. (kept coming back EVERY time the machine or the vbox guests come online) but I am done with this issue, got tried of being told that what I was seeing wasn't really happening, checked the ignore box on last boot. thanks but I don't have the knowledge time or want to even look at the SE Linux trouble shooting browser at every boot for something that people tell me can't be happening. hoepfully some patch at some point in the future will take care of whatever is going on here.
Please attach the output of # ausearch -m avc -ts recent This will show the most recent AVC. If you get this AVC at boot time then it is something different. Mark I am just trying to understand if this is involved with installing packages or something else. It would probably be best to open a new bug, since you are convinced that the fix of the original bug does not fix your problem.
i :) I have not been following this closely and do not understand what is going on but i think people generally try to say when a bug appears to have been fixed on their own system just in case that helps other people either fix their own systems problem or helps a developer pin-point exactly what the trouble is and therefore how to fix it. My own problem with this bug appears to have been fixed but i can't remember how my system kept popping up with this bug in the first place. I think my system is fixed but am not sure. Sorry that's not very helpful! If you are able to walk away from the problem and don't have time to try to help the devs work out what is wrong then other people may find they have the same problem and may be able to continue the troubleshooting that you started. The devs may work out the problem even without the troubleshooting help of course. Anyway, the point is that it was good to "get the ball rolling" and it is fine to walk away if you don't have enough time to continue. We need to operate as a team rather than relying on 1 or 2 individuals to fix everything about any problem. Good work, thanks and good luck to all Many regards from Tom :)
[root@localhost Mark]# ausearch -m avc -ts recent <no matches> ever since I hit the "ignore" box on the SELinux Troublshooter/Bug Reporter tool it hasn't come up and hasn't been an issue. it's not that I don't appreacate people working on fixing things, but being told the pop ups I was getting every day was fixed to the world was kind of a put off when I was getting it every day. I would love to have the indepth know how to actually get the information people need to fix these problems but frankly I don't know what to run, and when I do run things people tell me to I get output that either doesn't make sense, or I get output that people tell me I shouldn't get. I just know the SELinux trouble shooter spit messages at me every boot untill I clicked the "ignore" box on the issue. since I told it to ignore and stop bothering me about /tmp/ file premissions.
ausearch -m avc -i Will show you all messages, including the last time you received one.
Hi :) Don't worry about not understanding yet. I don't either. As i bump into other bugs things will hopefully make a bit more sense. I try to follow instructions where i can but there is not always time. Until then ... http://catb.org/jargon/html/koans.html#id3141171 Good luck and regards from Tom :)
Just thought that I would add that I have the latest "testing" and this bug is still occurring ;-) Occurs with package manager...
What does the following output ls -lZ /usr/libexec/packagekitd -rwxr-xr-x. root root system_u:object_r:rpm_exec_t:s0 /usr/libexec/packagekitd
Bug still seems to be occuring. ls -lZ /usr/libexec/packagekitd -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/libexec/packagekitd selinux-policy-3.7.19-62.fc13.noarch
If restorecon /usr/libexec/packagekitd Does not change the context, try yum reinstall selinux-policy-targeted And look for errors.
*** Bug 671129 has been marked as a duplicate of this bug. ***
*** Bug 682961 has been marked as a duplicate of this bug. ***