GNOME Bugzilla – Bug 558181
gnome-keyring-daemon started via pam_gnome_keyring.so cannot read gconf
Last modified: 2008-12-12 20:17:57 UTC
Please describe the problem: When gnome-keyring-daemon is started via pam_gnome_keyring.so, it cannot access gconf to read the daemon-components configuration, and thus ignores that configuration. It cannot access gconf, because as of 2.24, gconf now requires that dbus be running, which it is not, so early in the login sequence. A problem caused by this is that it is now impossible to disable modules of gnome-keyring-daemon that you do not want, if it is launched from pam_gnome_keyring.so. Steps to reproduce: Take any setup (e.g. Ubuntu Intrepid default install) with GNOME 2.24, and the pam_gnome_keyring.so configured in the gdm pam stack. Using gconf-editor or otherwise, set /apps/gnome-keyring/daemon-components/ssh to false. Log out and log in. Actual results: Observe that despite being turned off in gconf, the /tmp/keyring-XXXXXX/ssh socket still exists and $SSH_AUTH_SOCK has been set to it. Observe that in /var/log/auth.log or wherever syslog authpriv messages are logged, there are errors reporting that gnome-keyring could not read gconf. Expected results: gnome-keyring-daemon should be able to read its gconf settings so that it can honour them. Does this happen every time? Yes. Other information:
Hm, ugh. Maybe change pam_gnome_keyring module to spawn a very limited daemon which just holds onto the password and will write it once over a Unix domain socket; then later in the login process when gnome-keyring-daemon is started it reads the address of the socket from the environment (which PAM can set).
Is there any practical way to allow read-only gconf access without a dbus?
Anything is possible, it's more a question of what's least hacky. We could try to bring up more of the desktop infrastructure inside PAM, but it's going to be easier for SELinux policy and the like if what we do inside PAM is very limited.
So let me enumerate some options in a random order: * Create a PAM module that spawns the session bus before we want to do anything else. Or just wedge that into pam_gnome_keyring. * Do the daemon-holding-password hack above * Try to make some official PAM API to keep track of a password * Add a special bootstrapping GConf API
Sort of leaning towards having pam_gnome_keyring spawn the session bus if it doesn't exist yet.
See also http://bugzilla.gnome.org/show_bug.cgi?id=547272
This is a toughy. Another option would be to have gnome-keyring not use gconf for telling it which components to start. Perhaps using desktop files of some sort? FWIW, the mythical 'DConf' allows reads without a running daemon: http://live.gnome.org/dconf
Fixed. When run with --login much of the initialization is delayed until we get proper environment variables. Documented here: http://live.gnome.org/GnomeKeyring/RunningDaemon http://live.gnome.org/GnomeKeyring/Distributors 2008-12-11 Stef Walter <stef@memberwebs.com> * common/gkr-crypto.c: * common/gkr-secure-memory.c: * common/gkr-secure-memory.h: * daemon/gkr-daemon.c: * daemon/gkr-daemon.h: * daemon/gkr-daemon-dbus.c: * daemon/gkr-daemon-ops.c: * pam/gkr-pam-module.c: Rework initialization of the daemon so that most initialization can happen after starting via PAM. Fixes bug #558181 * library/gnome-keyring.c: * library/gnome-keyring-private.h: * library/gnome-keyring-socket.c: Don't let --start use an autostart DBus daemon.
Not quite good enough, yet. I think. There are pam configurations (fingerprint, smart card) where we have no password, and thus start g-k-d without --login. So in those cases we'll still have the problem.
Have you tested this assumption? The way it's coded and supposed to work is that gnome-keyring installs an autostart desktop file. This desktop file runs g-k-d with the '--start' option. gnome-session runs this autostart file.At this point if there's no running daemon (ie: because of a lack of PAM module installed), it becomes *the* g-k-d for the user's session. Or am I missing something?
I was probably just confused, and g-p-m was really started by gnome-session. I will check again next time I play with fingerprints. Everybody gets confused by gnome-keyring... Sorry for the noise.
Thanks for fixing this!
You're welcome. Apologies for the complexity. gnome-keyring ties together a lot of disparate technologies, which causes some of the simpler approaches to not fit the bill. However, over time, we've been trying to simplify things as much as possible.