GNOME Bugzilla – Bug 691269
lock screen with pam_krb5 authentication doesn't update ticket cache
Last modified: 2013-12-04 03:17:09 UTC
Up to and including gnome-shell 3.4 I used to have auth [success=1 default=ignore] pam_krb5.so ignore_root try_first_pass before auth required pam_unix.so try_first_pass likeauth nullok in my gdm-password and gnome-screensaver pam stacks. Since 3.6, this doesn't work anymore. gdm creates a new ticket cache of the form krb5cc_1000_XXXXXX (where XXXXXX is a random base64 string) every time I authenticate after screen lock but the KRB5CCNAME doesn't get updated and the old ticket caches don't get cleaned up. When I read the environment the during login and lock authentication the only difference is the PPID. That suggests to me that during lock authentication, a new gdm instance is created which authenticates the user and whose context (including the KRB5CCNAME environment variable) is destroyed after authentication. I'm not sure if this is the intended behaviour, it sure confused me. My workaround is to specify a static ticket cache for each user (eliminating the XXXXXX random part of the ticket cache), so no matter what PID writes the ticket cache, it always ends up in the same file. I'm not sure yet if that has any negative implications on krb5 authentication.
Ray, any idea ?
probably a gdm bug, moving
so the issue, I think is we don't create the KRB5CCNAME environment variable until we fork the session: gdm-session-worker.c gdm_session_worker_start_session: session_pid = fork ();• ... if (session_pid == 0) {• ... kerberos_cache = gdm_session_worker_get_environment_variable (worker, "KRB5CCNAME");• if (kerberos_cache == NULL) {• kerberos_dir = g_strdup_printf ("/run/user/%d/krb5cc_%s",• (int) getuid(),• g_dbus_connection_get_guid (worker->priv->connection));• ... execve (startp, argv, envp);• But the process that handles reauthentication is off the parent. So, we really need to do that before we fork. Of course, we're only doing this, at all, because the defaults weren't set to change upstream until 1.11. 1.11 is out now. we should see if the defaults changed and potentially just drop the above lines completely.
This might be completely unrelated: I'm using Arch Linux and the new update made pam_krb5 not work at all anymore. klist shows the ticket cache is now supposed to be in /run/user no matter what I set in pam_krb5 ccache and ccache_dir. I've now found that there are two projects pam-krb5 (http://www.eyrie.org/~eagle/software/pam-krb5/) and pam_krb5 (https://fedorahosted.org/pam_krb5/) and according to the project pages they don't seem related in any way. Arch Linux only provides a package for pam-krb5. It seems that ubuntu is using pam_krb5 (not only fedora/red hat) , so I'll create a new package for pam_krb5 in Arch as soon as I get to it and test it. Just to make sure we have similar environments. And from what I could read, there are no plans for pam-krb5 to implement the DIR type and support /run/user ticket caches. Having said that, Ray's analysis sounds like it describes what I'm experiencing. However, I'm using krb5-1.11 already (current package in Arch). I'll report back as soon as I get pam_krb5 running.
i'll attach something that should fix things up.
Created attachment 233016 [details] [review] worker: set KRB5CCNAME before forking We need it to be set in the parent so it's available for reauthentication.
Ray, I'm sorry to have to report that the patch seemingly didn't change anything regarding the situation. I had installed the fedora pam_krb5 and applied your patch. Still, there is a new ticket cache every time I lock the screen and reauthenticate but the original one for the current session stays the same (isn't updated). Can I help out with any debugging information?
i'll try to reproduce and work from there.
I've got reports downstream that GDM is calling pam_setcred with the wrong argument: Nov 19 10:38:56 blah gdm-password]: pam_krb5[2258]: pam_setcred(PAM_ESTABLISH_CRED) returning 0 (Success) instead of Nov 19 10:38:56 blah gdm-password]: pam_krb5[2258]: pam_setcred(PAM_REINITIALIZE_CRED) returning 0 (Success) in /var/log/secure . That's probably the cause of this bug.
we do have if (!worker->priv->is_reauth_session) {• worker->priv->cred_flags = PAM_ESTABLISH_CRED;• } else {• worker->priv->cred_flags = PAM_REINITIALIZE_CRED;• }• • in the code, but it must not be getting run (or something). Will investigate.
Chatted a bit with mclasen on irc, who started to look into this issue. The worker used for reauthentication doesn't have GDM_SESSION_FOR_REAUTH in its environment. That led us to discover we never actually set the worker to be a "reauthentication" worker. We probably need something like: --- a/daemon/gdm-session.c +++ b/daemon/gdm-session.c @@ -1752,4 +1752,6 @@ start_conversation (GdmSession *self, gdm_session_worker_job_set_server_address (conversation->job, g_dbus_server_get_client_address (self->priv->worker_server)); + gdm_session_worker_job_set_for_reauth (conversation->job, + self->priv->verification_mode == GDM_SESSION_VERIFICATION_MODE_REAUTHENTICATE); if (self->priv->conversation_environment != NULL) { I'll confirm that fixes things tomorrow.
Created attachment 260382 [details] [review] session: set reauth sessions as such Reauthentication sessions need subtly different behavior than initial login sessions with regard to pam. For instance, we want to refresh existing kerberos credentials instead of establishing new kerberos credentials. GDM has all the code in place to do this properly, but lacks the actual call to mark reauthentication sessions as such. This commit adds the missing call.
The above patch fixes things for me, so I'll go ahead and push it.
Attachment 260382 [details] pushed as 16db34e - session: set reauth sessions as such
*** Bug 710499 has been marked as a duplicate of this bug. ***