Weblog entry #30 for dkg
See all weblog entries made by dkg.
One of the problems i ran into with this arrangement happened because i was following the pam_mount configuration instructions too literally. In particular, README.Debian.gz says:
For every application used for logging in, there is a file of the form /etc/pam.d/xyz, add the following line at the end of the file:In particular, ubuntu's /etc/pam.d/gdm defaults to:
@include common-pammount
#%PAM-1.0 auth requisite pam_nologin.so auth required pam_env.so readenv=1 auth required pam_env.so readenv=1 envfile=/etc/default/locale @include common-auth auth optional pam_gnome_keyring.so @include common-account session required pam_limits.so @include common-session session optional pam_gnome_keyring.so auto_start @include common-passwordWhen i added the @include common-pammount directive to the bottom of this file when using pam_mount, new GNOME sessions failed badly: the gnome-panel didn't appear (which means that the user couldn't log out conveniently), and two error messages popped up at each login with nasty details like:
No database available to save your configuration: Unable to store a value at [...], as the configuration server has no writable databases.
The problem seems to be that libpam-gnome-keyring actually kicks off gconfd-2 during its PAM session invocation. If that comes before libpam-mount's PAM session invocation, then the home directory isn't mounted for the keyring, and gconfd-2 decides that it is unable to save any settings. Since gconfd then persists for the rest of the session, further GNOME session components try to talk to it and it refuses, even though the gconf db is now available (via the mounted homedir).
Since the order of the lines in a /etc/pam.d/* are semantically relevant, i'm usually very reluctant to tamper with the defaults. However, i think the correct /etc/pam.d/gdm for this scenario (or any pam-mount scenario using GNOME where the homedir might not be present at all before the session) is actually:
#%PAM-1.0 auth requisite pam_nologin.so auth required pam_env.so readenv=1 auth required pam_env.so readenv=1 envfile=/etc/default/locale @include common-auth @include common-account session required pam_limits.so @include common-session @include common-password @include common-pammount auth optional pam_gnome_keyring.so session optional pam_gnome_keyring.so auto_startWith this configuration in place, i can successfully log in with a test user, anyway (and move on to the next problem, which appears to be SQLite over CIFS, ugh).
These sorts of problems are tough to nail down:
- Is this overall problem due to a bug in the documentation for libpam-mount?
- In gdm for its default weirdly-ordered PAM config?
- In libpam-gnome-keyring for launching gconf-d-2 in the first place?
- In libgconf2-4 for gconfd-2 not being able to notice when the directories it wants become available?
Comments on this Entry
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
But an X11 login -- or rather, i should say, a GNOME login -- fails far more often than not. FWICT, this is because many of the GNOME daemons deliberately detach and orphan themselves from the session. Since they're children of PID 1, they can't be easily cleaned up or signaled by session shutdown. So the session closes, and things like tracker, gconf-d, and bonobo-activation-server persist, if only for a minute or two.
Well, that minute is long enough to make it so that pam_mount can't unmount the home directory. If you've got an encrypted home directory, that's a security concern. If you're mounting a network-offered directory with multiple home directories on it (but only mounting one at a time, depending on who's logged in at the console), you've got other problems, because the previous user's permissions will be set on the mountpoint when the next user tries to log in.
[ Parent | Reply to this comment ]
Changing:
@include common-auth
gnome-keyring auth
@include common-session
gnome-keyring session
Into:
@include common-auth
@include common-session
gnome-keyring auth
gnome-keyring session
really shouldn't change anything, or that looks like a PAM bug.
I'm happy to update the PAM config if I can understand how it helps. :)
--
Loic Minier
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
/etc/pam.d/common-pammount includes both auth and session directives. So with the initial ordering of the /etc/pam.d/gdm, there's no way to cleanly insert the @include line such that it's after the common-auth and common-session, but before the gnome-keyring business.
I think so, anyway. Even better would be if gnome-keyring wouldn't need access to the user's homedir, or if gconfd-2 would be able to recover more gracefully from such a sequence of events, since not everyone will use pam_mount to mount their homedir, e.g. some crypted-homedir arrangements.
Thanks for thinking about this, Loic. If i can do other debugging, let me know.
[ Parent | Reply to this comment ]
Instead of touching gdm, could you try adding @include common-pammount to the end of both common-auth and common-session?
--
Loic Minier
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
What's more, /etc/pam.d/common-pammount contains both auth and session directives, so even if i did want pam_mount to trigger for every type of PAM-triggered connection, if it was included in common-auth and common-session, those directives would be duplicated (which would try to mount the homedir twice, afacit):
0 root@mew:~# grep '^[^#]' /etc/pam.d/common-pammount auth required pam_mount.so try_first_pass session required pam_mount.so try_first_pass 0 root@mew:~#
[ Parent | Reply to this comment ]
So while I could shuffle lines around in the gdm PAM configs, I think we should avoid it as:
- it would cause a conffile prompt for all systems where the gdm config was touched, probably more systems than systems with pammount
- it would be less readable than the current one
If this makes sense, then perhaps you should request that common-pammount be split in two files; on your side, you could simply copy-paste its contents in the proper place of the gdm PAM config in the mean time.
What do you think?
--
Loic Minier
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
I'll file a bug against libpam-mount about its documentation and default config later today. Approaching this from the other angle, is there anything that could be done to make the GNOME side of things more robust in the face of a not-yet-mounted homedir during PAM session initiation?
For example, should i be filing a bug against libpam-gnome-keyring for kicking off gconfd-2 when $HOME isn't present? or against libgconf2-4 for gconfd-2's inability to cope with a $HOME that is created or mounted after gconfd-2 is started? Or is there some other way GNOME could address this?
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
Some PAM modules require a mounted home directory (eg. pam_gnome_keyring used in gdm). These modules have to be moved after the common-pammount include if home directories are mounted.I'm not convinced that this is the best arrangement, as it seems likely to keep causing confusion, particularly for people who tend to go with the defaults. Those folks will get both gnome (including gnome-keyring) and will probably read just enough of README.Debian to see common-pammount. But the problem is documented at least, even if the simple case isn't as simple as it might be. And i've moved on to struggling over other issues ;) If other folks wanted to propose a superior solution and push for it, i'd be happy to weigh in again though, if you think that would be useful.
[ Parent | Reply to this comment ]