Comment 8 for bug 1296276

I took a closer look at the code. It looks like whatever is going on here
is more complicated than just the screen locker not using PAM properly,
although there is one error here:

    /* If nothing to run just refresh credentials because we successfully authenticated */
    if (command_argc == 0)
    {
        pam_setcred (pam_handle, PAM_REINITIALIZE_CRED);
        return EXIT_SUCCESS;
    }

This needs to check the return status of pam_setcred and report any
errors, and it needs to call pam_end like all of the other exit paths of
this function. The lack of a call to pam_end is why the *_pam_* ticket
cache is being leaked.

However, I suspect the actual problem is that this program is being run as
root and isn't told where the user's ticket cache is. I'm curious if
there's another ticket cache that shows up somewhere (probably
/tmp/krb5cc_0) because the credentials are being written out to the
default ticket cache location for root instead of to the user's session
ticket cache as determined by KRB5CCNAME. The problem, in turn, would be
that this program isn't inheriting the environment of the user's session.
I'm not at all clear on exactly how it's run, but it appears to be run as
root rather than as the user, which may indicate that it's being started
by some other system service rather than by the user.

One thing to try is to add "debug" to the arguments of pam_krb5.so in
/etc/pam.d/common-auth and then look in syslog after unlocking the
screen. That should provide much more detail about exactly what the
Kerberos PAM module is trying to do.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>