FWIW, this issue is also present using gdm3 in Ubuntu 16.04. With pam_krb5's debug option set, I see the following during initial login (with successful credential cache construction):
The _0 cache that is created has the correct new credential in it, but is obviously not known by any other process as it does not match the earlier version of $KRB5CCNAME. I imagine this is the same issue described above where the $KRB5CCNAME environment variable is not available in the gdm context which unlocks the screen.
It's worth noting that in the GDM case, there appears to be a per-session helper process (gdm-session-worker) used to communicate with the GDM service. This process _does not_ have the $KRB5CCNAME variable set in its environment. Would storing the value in this processes environment fix the problem?
FWIW, this issue is also present using gdm3 in Ubuntu 16.04. With pam_krb5's debug option set, I see the following during initial login (with successful credential cache construction):
gdm-password]: pam_krb5( gdm-password: auth): pam_sm_ authenticate: entry gdm-password: auth): (user cgallek) attempting authentication as <email address hidden> gdm-password: auth): user cgallek authenticated as <email address hidden> gdm-password: auth): (user cgallek) temporarily storing credentials in /tmp/krb5cc_ pam_LB8CeL gdm-password: auth): pam_sm_ authenticate: exit (success) gdm-password: setcred) : pam_sm_setcred: entry (establish) gdm-password: setcred) : (user cgallek) initializing ticket cache FILE:/tmp/ krb5cc_ 1000_3BiTY0 gdm-password: setcred) : pam_sm_setcred: exit (success)
gdm-password]: pam_krb5(
gdm-password]: pam_krb5(
gdm-password]: pam_krb5(
gdm-password]: pam_krb5(
gdm-password]: pam_krb5(
gdm-password]: pam_krb5(
gdm-password]: pam_krb5(
When unlocking the screen, I see the following successful credential refresh, but to the wrong cache filename (/tmp/krb5cc_0):
gdm-password]: pam_krb5( gdm-password: auth): pam_sm_ authenticate: entry gdm-password: auth): (user cgallek) attempting authentication as <email address hidden> gdm-password: auth): user cgallek authenticated as <email address hidden> gdm-password: auth): (user cgallek) temporarily storing credentials in /tmp/krb5cc_ pam_Dkg5Ip gdm-password: auth): pam_sm_ authenticate: exit (success) gdm-password: setcred) : pam_sm_setcred: entry (reinit) gdm-password: setcred) : (user cgallek) refreshing ticket cache /tmp/krb5cc_0 gdm-password: setcred) : pam_sm_setcred: exit (success)
gdm-password]: pam_krb5(
gdm-password]: pam_krb5(
gdm-password]: pam_krb5(
gdm-password]: pam_krb5(
gdm-password]: pam_krb5(
gdm-password]: pam_krb5(
gdm-password]: pam_krb5(
The _0 cache that is created has the correct new credential in it, but is obviously not known by any other process as it does not match the earlier version of $KRB5CCNAME. I imagine this is the same issue described above where the $KRB5CCNAME environment variable is not available in the gdm context which unlocks the screen.
It's worth noting that in the GDM case, there appears to be a per-session helper process (gdm-session- worker) used to communicate with the GDM service. This process _does not_ have the $KRB5CCNAME variable set in its environment. Would storing the value in this processes environment fix the problem?
~: ps -ef | grep gdm-session-worker
root 11364 11203 0 Jun25 ? 00:00:00 gdm-session-worker [pam/gdm-password]
~: cat /proc/11364/environ US.UTF- 8PATH=/ usr/local/ sbin:/usr/ local/bin: /usr/sbin: /usr/bin: /sbin:/ binGDM_ SESSION_ DBUS_ADDRESS= unix:abstract= /tmp/dbus- oTnmcExV
LANG=en_