Additional info: libreport version: 2.0.13 kernel: 3.6.0-0.rc6.git0.2.fc18.i686.PAE description: :SELinux is preventing /usr/bin/dbus-daemon from 'execute' accesses on the file /usr/libexec/mission-control-5. : :***** Plugin catchall (100. confidence) suggests *************************** : :If you believe that dbus-daemon should be allowed execute access on the mission-control-5 file 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 dbus-daemon /var/log/audit/audit.log | audit2allow -M mypol :# semodule -i mypol.pp : :Additional Information: :Source Context system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 :Target Context system_u:object_r:telepathy_mission_control_exec_t : :s0 :Target Objects /usr/libexec/mission-control-5 [ file ] :Source dbus-daemon :Source Path /usr/bin/dbus-daemon :Port <Unknown> :Host (removed) :Source RPM Packages dbus-1.6.0-2.fc18.i686 :Target RPM Packages telepathy-mission-control-5.13.1-1.fc18.i686 :Policy RPM selinux-policy-3.11.1-21.fc18.noarch :Selinux Enabled True :Policy Type targeted :Enforcing Mode Enforcing :Host Name (removed) :Platform Linux (removed) 3.6.0-0.rc6.git0.2.fc18.i686.PAE : #1 SMP Mon Sep 17 17:28:04 UTC 2012 i686 i686 :Alert Count 1 :First Seen 2012-09-23 22:24:15 EDT :Last Seen 2012-09-23 22:24:15 EDT :Local ID f4a4bce4-036a-40d9-b442-89c918d3fefe : :Raw Audit Messages :type=AVC msg=audit(1348453455.18:289): avc: denied { execute } for pid=1323 comm="dbus-daemon" name="mission-control-5" dev="sda1" ino=794234 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:telepathy_mission_control_exec_t:s0 tclass=file : : :type=SYSCALL msg=audit(1348453455.18:289): arch=i386 syscall=execve success=no exit=EACCES a0=91f63a0 a1=91f6348 a2=91f6830 a3=17 items=0 ppid=1322 pid=1323 auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 egid=42 sgid=42 fsgid=42 tty=(none) ses=4294967295 comm=dbus-daemon exe=/usr/bin/dbus-daemon subj=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 key=(null) : :Hash: dbus-daemon,xdm_dbusd_t,telepathy_mission_control_exec_t,file,execute : :audit2allow : :#============= xdm_dbusd_t ============== :allow xdm_dbusd_t telepathy_mission_control_exec_t:file execute; : :audit2allow -R : :#============= xdm_dbusd_t ============== :allow xdm_dbusd_t telepathy_mission_control_exec_t:file execute; :
Created attachment 616338 [details] File: type
Created attachment 616339 [details] File: hashmarkername
Mikhail , what does # id -Z # ps -eZ |grep dbus
[root@localhost ~]# id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [root@localhost ~]# ps -eZ |grep dbus system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 495 ? 00:00:02 dbus-daemon unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 1148 ? 00:00:00 dbus-launch unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 1149 ? 00:00:29 dbus-daemon unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 1314 ? 00:00:00 dbus-daemon
It looks correct. And are you able to reproduce it? I mean if you log out/in and run empathy, does it happens again?
This looks like something gdm is doing potentially buried within a .profile somewhere.
1. Logged in to user account. 2. SELinux raised the issue noted. Package: (null) Architecture: x86_64 OS Release: Fedora release 18 (Spherical Cow)
Ray is the login program doing something with telepathy?
gnome-shell might be
(though shouldn't be)
I would figure this is something added to /etc/profiles which gdm is hitting.
*** Bug 862150 has been marked as a duplicate of this bug. ***
*** Bug 862148 has been marked as a duplicate of this bug. ***
*** Bug 862156 has been marked as a duplicate of this bug. ***
*** Bug 863683 has been marked as a duplicate of this bug. ***
I hit a number of other mission-control related AVCs also; see bug 865770
After a timeout (old screensaver mode but F18 mode), I am unable to log into the system directly. I have to select switch user, then I have to log in as myself, and voila, there you have it, I am able to recognize the selenix error and to write this note. Similar problems with sudo, Package: (null) OS Release: Fedora release 18 (Spherical Cow)
I saw this after upgrading F17->F18 and logging in. Package: (null) OS Release: Fedora release 18 (Spherical Cow)
So just after upgrade or you can able to reproduce it after every login.
I think something in /etc/profile.d? grep mission /etc/profile.d/*
I saw this only once, on the first login. There is no "mission-control" inside files in /etc/ except for /etc/selinux and some binary caches (prelink and stuff). There is also no "mission-control" inside my home.
It's probably dbus activation of /usr/share/dbus-1/services/org.freedesktop.Telepathy.AccountManager.service
I got this error so often I finally got tired of seeing it and disabled SELinux notifications. I would see a dozen of the errors every few minutes. I tried all of the options suggested by SELinux but none of them worked as I continued to see the errors after doing as suggested. I even tried clearing out my home directory and rebuilding it from scratch. I still continued seeing the errors.
D. Charles Pyle What did you try?
Gnome shell/gdm should not be executing telepathy, when the machine is not logged in.
I see this with selinux-policy-3.11.1-50 and gnome-shell-3.6.2-2.fc18
(In reply to comment #24) > D. Charles Pyle > > What did you try? I tried everything that SELinux Troubleshooter suggested for me to do. Restorecon, and all the rest of the suggestions offered by SELinux Troubleshooter, depending on the error, I tried. I also had SELinux relabel the entire drive--multiple times and after each and every update to selinux-policy. Nothing helped and I continued receiving the errors up to a dozen times every few minutes. I got so fed up with seeing the errors every few minutes and having processes blocked so I turned off notifications and set it to permissive. At least it is better than it was a few months ago when I was told at bootup that no suitable policy file could be found even though it was there and installed. But I can't have my work flow interrupted by constant reporting of SELinux errors and constant blocking of processes that are integral to what I was doing. It was even blocking memory processes belonging to wine and making it so that certain of my Windows programs that I run under wine would not work properly. So, as I said, I set SELinux to permissive and turned off notifications weeks ago. I am open to suggestions as to new things to try.
Login session Package: (null) Architecture: x86_64 OS Release: Fedora release 18 (Spherical Cow)
*** Bug 906211 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Description of problem: Logged in, perhaps - saw selinux troubleshoot shortly after login Additional info: reporter: libreport-2.1.9 hashmarkername: setroubleshoot kernel: 3.11.10-100.fc18.x86_64 type: libreport