SELinux is preventing /bin/dbus-daemon from 'execute' accesses on the file /usr/bin/gnome-keyring-daemon. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that dbus-daemon should be allowed execute access on the gnome-keyring-daemon 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:gkeyringd_exec_t:s0 Target Objects /usr/bin/gnome-keyring-daemon [ file ] Source dbus-daemon Source Path /bin/dbus-daemon Port <Unknown> Host (removed) Source RPM Packages dbus-1.4.6-4.fc15 Target RPM Packages gnome-keyring-3.0.2-1.fc15 Policy RPM selinux-policy-3.9.16-24.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 2.6.38.6-26.rc1.fc15.x86_64 #1 SMP Mon May 9 20:45:15 UTC 2011 x86_64 x86_64 Alert Count 1 First Seen sun 22.maí 2011, 11:58:08 GMT Last Seen sun 22.maí 2011, 11:58:08 GMT Local ID f06189d0-ed9d-425e-af43-ffc9db790f22 Raw Audit Messages type=AVC msg=audit(1306065488.258:52): avc: denied { execute } for pid=1624 comm="dbus-daemon" name="gnome-keyring-daemon" dev=sdb10 ino=1056640 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gkeyringd_exec_t:s0 tclass=file type=SYSCALL msg=audit(1306065488.258:52): arch=x86_64 syscall=execve success=no exit=EACCES a0=7f187521f590 a1=7f187521f4f0 a2=7f187521f670 a3=7fffeb60f2e0 items=0 ppid=1623 pid=1624 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=/bin/dbus-daemon subj=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 key=(null) Hash: dbus-daemon,xdm_dbusd_t,gkeyringd_exec_t,file,execute audit2allow #============= xdm_dbusd_t ============== allow xdm_dbusd_t gkeyringd_exec_t:file execute; audit2allow -R #============= xdm_dbusd_t ============== allow xdm_dbusd_t gkeyringd_exec_t:file execute;
Do you know what you were you doing when this happened?
Same thing happened to me a couple of minutes ago. I left my laptop on, went out for a couple of hours, and it went into suspension mode. When resuming from suspension, after entering my account password it said it was "incorrect" (even though it was not) and logged in anyway. Then that same warning came up. I'm no fedora-guru but, shouldn't dbus-daemon be actually allowed access to gnome-keyring-daemon by default?
#comment 1 >Do you know what you were you doing when this happened? No. There is only one occurrance in SE alert list.
Did you setup gnome-keyring as the mechanism to log you in?
*** Bug 709481 has been marked as a duplicate of this bug. ***
Both of these AVC's show the gnome-keyring-daemon running as UID 42. It looks like the dbus daemon is trying to launch it under then gnome-keyring UID.
I mean gdm UID.
#4 I have gnome-keyring-3.0.2-1.fc15.x86_64
Jeremias, this AVC is showing gdm's dbus running under its UID (42) trying to execute gnome-keyring-daemon. gdm starting a user shell and then the users dbus starting gnome-keyring-daemon, is allowed.
I think I get what you mean. It hasn't happened again so far. Could it be possible that when I resumed from suspension, the system "mistakenly thought" I was user GDM? Remember I told you I got a "wrong password" alert when logging in, even though password was properly entered, but logged in anyway. Then the AVC popped up. As I said before, I'm no fedora-expert so this could just be nonsense lol
That guess is as good as any. We have seen it on a couple of machines, but it does not seem to be happening regularly.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This happened to me on login to "Classic GNOME with Compiz". I do have ssh keys.
This just happened to me while resuming from suspend on a Dell M102z Laptop. Default F15 / gnome-shell setup with all updates installed. I didn't make any fancy changes to the login system or gnome-keyring or how the laptop suspends/resumes.
Ray, does gdm execute a script on behalf of a user on a resume, without setting the SELinux context? Does this go through the pam stack?
*** Bug 750745 has been marked as a duplicate of this bug. ***
*** Bug 768743 has been marked as a duplicate of this bug. ***
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached 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 to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping