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 691269 - lock screen with pam_krb5 authentication doesn't update ticket cache
lock screen with pam_krb5 authentication doesn't update ticket cache
Status: RESOLVED FIXED
Product: gdm
Classification: Core
Component: general
3.6.x
Other Linux
: Normal normal
: ---
Assigned To: GDM maintainers
GDM maintainers
: 710499 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-01-07 06:11 UTC by Reiner Merk
Modified: 2013-12-04 03:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
worker: set KRB5CCNAME before forking (8.44 KB, patch)
2013-01-08 20:55 UTC, Ray Strode [halfline]
none Details | Review
session: set reauth sessions as such (2.69 KB, patch)
2013-11-20 19:28 UTC, Ray Strode [halfline]
committed Details | Review

Description Reiner Merk 2013-01-07 06:11:00 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.
Comment 1 Matthias Clasen 2013-01-07 11:11:50 UTC
Ray, any idea ?
Comment 2 Ray Strode [halfline] 2013-01-07 16:06:55 UTC
probably a gdm bug, moving
Comment 3 Ray Strode [halfline] 2013-01-07 16:14:30 UTC
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.
Comment 4 Reiner Merk 2013-01-08 09:14:55 UTC
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.
Comment 5 Ray Strode [halfline] 2013-01-08 20:55:33 UTC
i'll attach something that should fix things up.
Comment 6 Ray Strode [halfline] 2013-01-08 20:55:41 UTC
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.
Comment 7 Reiner Merk 2013-01-11 19:59:17 UTC
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?
Comment 8 Ray Strode [halfline] 2013-01-14 14:48:05 UTC
i'll try to reproduce and work from there.
Comment 9 Ray Strode [halfline] 2013-11-20 00:43:00 UTC
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.
Comment 10 Ray Strode [halfline] 2013-11-20 00:44:50 UTC
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.
Comment 11 Ray Strode [halfline] 2013-11-20 04:06:34 UTC
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.
Comment 12 Ray Strode [halfline] 2013-11-20 19:28:14 UTC
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.
Comment 13 Ray Strode [halfline] 2013-11-20 19:29:02 UTC
The above patch fixes things for me, so I'll go ahead and push it.
Comment 14 Ray Strode [halfline] 2013-11-20 19:44:31 UTC
Attachment 260382 [details] pushed as 16db34e - session: set reauth sessions as such
Comment 15 Ray Strode [halfline] 2013-12-04 03:17:09 UTC
*** Bug 710499 has been marked as a duplicate of this bug. ***