Testing F15-alpha, with both gnome, kde installed. Up-to-date as of Mar 14, cannot get any gnome-keyring-using app to save stuff on kde. Testing nm-applet, for example, I see console error output: ** Message: secret service operation failed: Failed to execute program /usr/bin/gnome-keyring-daemon: Success over and over, abrt-gui also has Can't connect to gnome-keyring-daemon, changes won't be saved. Ah, looking into /etc/xdg/autostart/gnome-keyring-secrets.desktop has OnlyShowIn=GNOME;LXDE;XFCE; Is there some purposeful reason to not include KDE here?
Tested modifying gnome-keyring-secrets.desktop to not exclude KDE makes it work Not sure how the other gnome-keyring autostart items: gnome-keying-gpg gnome-keying-pkcs11 gnome-keying-ssh may play a similar role in reduced functionality of apps run on KDE. Any comment or advice wrt these latter items would be appreciated as well.
I remember when we did the same thing for XFCE. IMHO the autostart condition should be removed altogether. Will discuss upstream. https://bugzilla.gnome.org/show_bug.cgi?id=644305 https://bugzilla.gnome.org/show_bug.cgi?id=610715 (although this was a slightly different issue)
I would tend to agree wrt autostart condition (or at worst, use NotShowIn for exceptions)
Discussed at 2011-04-15 blocker review meeting. Accepted as a blocker per criterion "# Saving passwords in the desktop default keyring (if the desktop implements one), and retrieving passwords from the keyring, must work " (it's a slight stretch as gnome-keyring isn't KDE's default keyring manager, but it's often used in KDE and some apps won't use KDE's keyring manager, we think). We suspect this may be fixed already; can someone check? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
So in a cursory look, I don't see any change which would fix this, but I also haven't done any testing to reproduce it. The upstream bug (which specifically requested the daemon to be set to autostart on login) got closed as NOTABUG, saying that gnome-keyring should be getting started through D-Bus activation in KDE. So it seems that the real bug is that this is (was?) not working.
(The idea is that KDE users might not need gnome-keyring running at all, depending on the applications they use. With D-Bus activation, it will get started automatically when something needs it.)
rex: can you try this with beta and see how it is at present?
Can confirm problem with my current (as of today, apr 18) f15/x86_64 laptop, trying to run abrt-gui on kde, I get an error dialog: "Cannot connect to gnome keyring daemon" (added similar comment on upstream bug too) (I can try too with a f15-beta live image if you insist though...)
debugging with stefw on #keyring @ irc.gimp.net: [04/18/11 11:46] <rdieter> stefw: ping, hi, Rex here from https://bugzilla.gnome.org/show_bug.cgi?id=644918 [04/18/11 11:46] <stefw> hey rdieter [04/18/11 11:46] <stefw> i'm sure you have dbus activation running and all? [04/18/11 11:47] <stefw> does abrt-gui use libgnome-keyring? [04/18/11 11:47] <stefw> ldd /path/to/abrt-gui [04/18/11 11:47] <rdieter> unsure, actually. [04/18/11 11:47] <stefw> would be a pretty good indication [04/18/11 11:47] <rdieter> lemme see [04/18/11 11:47] <rdieter> looks like it indeed does link against libgnome-keyring [04/18/11 11:47] <stefw> okay, that takes away one variable [04/18/11 11:48] <stefw> and it's probably libgnome-keyring 3.0.x or something like that. [04/18/11 11:48] <rdieter> though I could use a different app to test [04/18/11 11:48] <rdieter> libgnome-keyring-3.0.0-1.fc15 it is [04/18/11 11:48] <stefw> righto. [04/18/11 11:48] <stefw> so i assume gnome-keyring-daemon isn't running when you log into kde right? [04/18/11 11:49] <rdieter> correct [04/18/11 11:49] * rdieter still sees a bunch of keyring-related items in /etc/xdg/autostart too [04/18/11 11:49] <stefw> and what does this tell you [04/18/11 11:49] <stefw> grep -R org.freedesktop.secrets /usr/share/dbus-1/services/ [04/18/11 11:50] <rdieter> org.freedesktop.secrets.service (owned by gnome-keyring-3.0.0) [04/18/11 11:51] <stefw> okay, so kwalletd has a secret service implementation too, but it doesn't seem to be deployed yet... at least not on fedora. [04/18/11 11:51] <rdieter> anyway, the grep output is: org.freedesktop.secrets.service:Name=org.freedesktop.secrets [04/18/11 11:51] <stefw> right on [04/18/11 11:52] <stefw> any messages in /var/log/auth.log after 'Cannot connect to Gnome keyring daemon' [04/18/11 11:52] <stefw> btw, that message looks wierd, did you copy it into the bug report verbatim? [04/18/11 11:53] <rdieter> yes, though I transcribed it from another box, so may have a typo [04/18/11 11:53] <rdieter> my box has no /var/log/auth.log , I'll try grepping everything there [04/18/11 11:55] <rdieter> ah, here we go [04/18/11 11:55] <stefw> gnome-keyring-daemon logs to syslog 'auth' facility [04/18/11 11:56] <rdieter> localhost gnome-keyring-daemon[28643]: couldn't connect to dbus session bus: An SELinux policy prevents this sender from sending this message to this recipient (rejected message had sender "(unset)" interface "org.freedesktop.DBus" member "Hello" error name "(unset)" destination "org.freedesktop.DBus") [04/18/11 11:56] <rdieter> so looks like an selinux thing perhaps [04/18/11 11:56] <stefw> grumble. [04/18/11 11:56] <stefw> i guess file a bug at bugzilla.redhat.com [04/18/11 11:57] <stefw> sorry that you're getting the run around :/ [04/18/11 11:57] <rdieter> k (though I'm in permissive mode at the moment, that logged message should be purely informative, not actually blocking anything) [04/18/11 11:57] <rdieter> back to bz.rh.com [04/18/11 11:57] <stefw> this isn't informative: "couldn't connect to dbus session" [04/18/11 11:57] <stefw> it's gnome-keyring-daemon complaining [04/18/11 11:58] <stefw> i mean it's an actual error
Anyway, the Cliff's notes version of that dialog is that it would appear there's some selinux mojo possibly blocking the dbus activation of this service.
you can try booting with selinux=0 to force selinux entirely off (though it'll require a relabel at the next boot with it turned on), just to identify for sure if it's selinux we're running into here.
Yup, looks like we have a winner now, booting with selinux=0, things get further and gnome-keyring-daemon activates... though I do have in /var/log/messages: gnome-keyring-daemon[1399]: couldn't set environment variable in session: The name .org.gnome.SessionManager was not provided by any .service files (though that's not surprising)
so, let's re-assign.
What avc's are you seeing?
long relabel later, these seem to be the relevant snippets from /var/log/audit/audit.log: type=SELINUX_ERR msg=audit(1303155816.203:55): security_compute_sid: invalid context unconfined_u:unconfined_r:staff_gkeyringd_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gkeyringd_exec_t:s0 tclass=process type=SYSCALL msg=audit(1303155816.203:55): arch=c000003e syscall=59 success=yes exit=0 a0=7f39cc539cc0 a1=7f39cc539c20 a2=7f39cc5be1d0 a3=7fffb5f3d560 items=0 ppid=1928 pid=1929 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="gnome-keyring-d" exe="/usr/bin/gnome-keyring-daemon" subj=unconfined_u:unconfined_r:staff_gkeyringd_t:s0-s0:c0.c1023 key=(null)
Rex were you playing with confined users?
not to my knowledge
Very strange to have a staff_gkeyringd_t? This would not have caused the system to not boot though. Since this would happen at login time.
"This would not have caused the system to not boot though. Since this would happen at login time." No, it doesn't, that's not a reported symptom anywhere in the bug AFAICS. It's simply as described - gnome-keyring-daemon should get dbus activated when something tries to use it from within KDE, but doesn't (for Rex, at least). Rex, could you test with the Beta RC2 live image to discount any local config issues? Thanks!
Sorry I misread. We added some fixes to execute the keyring from the pam stack with the correct context. I am trying to remember what we did, and maybe this is working differently from the gdm to kdm.
It's getting activated through D-Bus here, I think we need a policy for that.
The same for me: [ 69.769305] type=1401 audit(1303287861.129:6): security_compute_sid: invalid context unconfined_u:unconfined_r:staff_gkeyringd_t:s0 for scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0 tcontext=system_u:object_r:gkeyringd_exec_t:s0 tclass=process
The problem is staff_gkeyringd_t is the wrong context. It should be unconfined_gkeyringd_t or just unconfined_t. This context should only happen with a staff_t user.
I believe this is being caused by. https://bugzilla.redhat.com/attachment.cgi?id=485554
When you log in what does id -Z Show?
There are two things here. According to http://live.gnome.org/GnomeKeyring/RunningDaemon, gnome-keyring-daemon must be initialized from the session startup. Which is not the case in KDE. I wonder if the pam module initialization takes place with KDM (probably yes) and if there's a hanging process waiting for initialization. In case there isn't any, gnome-keyring-daemon is autospawned from d-bus, trying to switch the context from unconfined_dbusd_t. In Gnome, gnome-keyring-daemon is autostarted by desktop session, running under standard user desktop context (most probably). D-bus is not involved here.
$ id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
I got to believe this is caused by someone calling pam_gnome_keyring. Does this get called in kde? Not in the stack? The standard transition unconfined_dbusd_t execs gnome-keyringd-daemon should trasition properly. The problem we were seeing was gnome-keyring-daemon launched out of pam_gnome_keyring was being executed as staff_t, which caused other stuff to blow up. When you log in in permissive mode what context is the keyring running under. ps -eZ | grep gnome-keyring
pam_gnome_keyring might be run from KDM. (Setting needinfo on rdieter because there's a question for him in comment #28.)
$ grep keyring /etc/pam.d/kdm auth optional pam_gnome_keyring.so session optional pam_gnome_keyring.so auto_start (pretty much the same as f14) $ abrt-gui (try to configure bugzilla plugin) ** Message: secret service operation failed: Failed to execute program /usr/bin/gnome-keyring-daemon: Success Can't connect to gnome-keyring-daemon, changes won't be saved. # setenforce 0 $ abrt-gui (same) ** Message: couldn't connect to dbus session bus Can't connect to gnome-keyring-daemon $ ps aux | grep gnome-keyring | grep -v grep (nothing) # grep ri keyring /var/log/* ... /var/log/audit/audit.log:type=SELINUX_ERR msg=audit(1304098755.120:52): security_compute_sid: invalid context undefined_u:unconfined_r:staff_gkeyringd_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tcontext=system.u:object_r:gkeyringd_exec_t:s0 tclass=process lots of these, same whether selinux enforcing or not.
Are more info. This is the abrt-gui doing this? Why is the abrt-gui running a pam stack?
I have a feeling consolehelper is rearing its ugly head?
I don't think consolehelper is involved here I'll try to get a full vm installed here, and find some other gnome-keyring-using app to gather more data
OK, reproducible with seahorse too. # type=SELINUX_ERR msg=audit(1304101539.188:73): security_compute_sid: invalid context unconfined_u:unconfined_r:staff_gkeyringd_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gkeyringd_exec_t:s0 tclass=process # type=SYSCALL msg=audit(1304101539.188:73): arch=c000003e syscall=59 success=no exit=-13 a0=7f40cc6ea730 a1=7f40cc761380 a2=7f40cc743c80 a3=7fff3747ec10 items=0 ppid=2400 pid=2401 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="dbus-daemon" exe="/bin/dbus-daemon" subj=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 key=(null) # type=SELINUX_ERR msg=audit(1304101539.228:74): security_compute_sid: invalid context unconfined_u:unconfined_r:staff_gkeyringd_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gkeyringd_exec_t:s0 tclass=process # type=SYSCALL msg=audit(1304101539.228:74): arch=c000003e syscall=59 success=no exit=-13 a0=7f40cc6ee280 a1=7f40cc761380 a2=7f40cc743c80 a3=7fff3747ec10 items=0 ppid=2402 pid=2403 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="dbus-daemon" exe="/bin/dbus-daemon" subj=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 key=(null) IN permissive mode, now seahorse errors with "couldn't communicate with key ring daemon". audit.log contains: # type=SELINUX_ERR msg=audit(1304101657.790:80): security_compute_sid: invalid context unconfined_u:unconfined_r:staff_gkeyringd_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gkeyringd_exec_t:s0 tclass=process # type=SYSCALL msg=audit(1304101657.790:80): arch=c000003e syscall=59 success=yes exit=0 a0=7f40cc6ee240 a1=7f40cc6ed220 a2=7f40cc83db60 a3=7fff3747ec10 items=0 ppid=2469 pid=2470 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="gnome-keyring-d" exe="/usr/bin/gnome-keyring-daemon" subj=unconfined_u:unconfined_r:staff_gkeyringd_t:s0-s0:c0.c1023 key=(null)
ps -eZ | grep staff
Ok I guess I have to setup kde. Any quick way to update my test message to kde? yum install kdm konsole\* Seems to be updating.
$ ps -eZ | grep staff (empty)
To install a minimal test environment you probably want (at least): yum install kdm kdebase-workspace (though theoretically could skip kdm, though that may be relevant for testing here). and to use kdm set /etc/sysconfig/desktop to include DISPLAYMANAGER="KDE"
Discussed at 2011-04-29 blocker review meeting (http://meetbot.fedoraproject.org/fedora-bugzappers/2011-04-29/f15-blocker-review.2011-04-29-17.00.html). Adamw was going to reach out to Rex for how to proceed, but it appears this bug is moving again. Be advised the Final TC1 compose is on Monday, 2011-05-02. Also, the Final RC compose is on Tuesday, 2011-05-10. http://rbergero.fedorapeople.org/schedules/f-15/f-15-releng-tasks.html
Confirmed same problem using gdm + kde login, so that *may* rule out anything DM-related.
and, reconfirmed issue remains after installing all of updates-testing (2011-04-29)
Try selinux-policy-3.9.16-19.fc15
Tested with selinux-policy-3.9.16-21.fc15 , seems A-OK now.
Rex, Thanks for helping me diagnose this problem. (And kicking me in the ass to actually fix it.)
*** Bug 701312 has been marked as a duplicate of this bug. ***
The fixed selinux-policy has gone stable, so closing. (I also confirmed this fix.) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers