After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 558181 - gnome-keyring-daemon started via pam_gnome_keyring.so cannot read gconf
gnome-keyring-daemon started via pam_gnome_keyring.so cannot read gconf
Status: RESOLVED FIXED
Product: gnome-keyring
Classification: Core
Component: general
2.24.x
Other All
: Normal normal
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2008-10-28 01:02 UTC by Max Bowsher
Modified: 2008-12-12 20:17 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24



Description Max Bowsher 2008-10-28 01:02:46 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:
Comment 1 Colin Walters 2008-10-28 02:46:58 UTC
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).
Comment 2 Max Bowsher 2008-10-28 03:16:26 UTC
Is there any practical way to allow read-only gconf access without a dbus?
Comment 3 Colin Walters 2008-10-28 13:54:16 UTC
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.
Comment 4 Colin Walters 2008-11-15 22:50:43 UTC
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
Comment 5 Colin Walters 2008-11-15 22:55:52 UTC
Sort of leaning towards having pam_gnome_keyring spawn the session bus if it doesn't exist yet.
Comment 6 Colin Walters 2008-11-15 23:00:59 UTC
See also http://bugzilla.gnome.org/show_bug.cgi?id=547272
Comment 7 Stef Walter 2008-11-16 01:07:08 UTC
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
Comment 8 Stef Walter 2008-12-11 23:34:33 UTC
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.
Comment 9 Matthias Clasen 2008-12-12 14:42:50 UTC
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.
Comment 10 Stef Walter 2008-12-12 15:36:28 UTC
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?

Comment 11 Matthias Clasen 2008-12-12 16:45:44 UTC
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.
Comment 12 Ray Strode [halfline] 2008-12-12 17:48:32 UTC
Thanks for fixing this!
Comment 13 Stef Walter 2008-12-12 20:17:57 UTC
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.