slim-1.3.4 ebuild does provide a kerberos ticket for a new session. This was fixed with patch 2690 but got dropped somewhere and is reapplied with patch 3043. By adding patch 2690 to an overlay of the slim-1.3.4 ebuild, kerberos works as expected.
This does seem to be a regression, but after googling I'm not sure that the patch is the proper solution for the issue (ie it may break other things). Will continue to look into it.
I need to confirm that the bug you have is unique to slim. Could you please test with the latest x11-apps/xdm and confirm that kerberos authentication is working there? If it isn't, then the issue is probably the way kerberos is set up.
tl;dr, pam is really complicated. I think the code in slim is not incorrect. We need your slim pam config (basically the context of /etc/pam.d/*, if possible) to know what modules you are using.
OK, I have installed the latest xdm (1.1.11-r1) and reverted to the latest slim from portage (1.3.4) and when I have logged in I have no credentials (klist shows nothing). When I use my overlay with patch 2690 applied I have credentials (klist shows a list). Just to be absolutely clear, I have applied patch 2690 and not 3043, which seems to contain a lot of other things unrelated to this particular issue. Given that this patch works (I now have my tickets, I didn't before) do you still need to see what is in my pam slim files or not? I do not see why this would help, but I can attach if you want me to. Its just a lot of work cos there are several files involved.
Yes please. It's good to hear that xdm also fails. Could you test (if it's not too much trouble) x11-misc/lightdm and see if that works with your kerberos setup?
(In reply to comment #5) > Yes please. > > It's good to hear that xdm also fails. Could you test (if it's not too much > trouble) x11-misc/lightdm and see if that works with your kerberos setup? I'll test slim at work (where my kerb setup is) and see if it works. I'm still thinking this patch is wrong. Everything should work with ESTABLISH_CRED; it bugs me that it appears not to. Robert, can you still include your pam config? -A
Here are the pam files... * pam.d/slim: # File autogenerated by pamd_mimic in pam eclass auth include system-local-login account include system-local-login session include system-local-login * pam.d/system-local-login: auth include system-login account include system-login password include system-login session include system-login * pam.d/system-login: auth required pam_tally2.so onerr=succeed auth required pam_shells.so auth required pam_nologin.so auth include system-auth account required pam_access.so account required pam_nologin.so account include system-auth account required pam_tally2.so onerr=succeed password include system-auth session optional pam_loginuid.so session required pam_env.so session optional pam_lastlog.so session include system-auth session optional pam_ck_connector.so nox11 session optional pam_motd.so motd=/etc/motd session optional pam_mail.so * pam.d/system-auth: #%PAM-1.0 # Kerberised and Huddled # auth required pam_env.so auth sufficient pam_krb5.so minimum_uid=500 auth sufficient pam_unix.so try_first_pass likeauth nullok auth required pam_deny.so account required pam_krb5.so minimum_uid=500 account required pam_unix.so password required pam_cracklib.so difok=2 minlen=12 retry=3 password sufficient pam_krb5.so try_first_pass use_authtok minimum_uid=500 password sufficient pam_unix.so try_first_pass use_authtok nullok md5 shadow password required pam_deny.so session optional pam_krb5.so minimum_uid=500 session required pam_unix.so session required pam_limits.so
OK, so I have confirmed that the patch, although allowing the kerberos ticket to be accessible to the user, does so in a rather wrong way. Testing with the code as-is (ie, pam_setcred(PAM_ESTABLISH_CRED) ), KRB5CCNAME is set to a proper cache file, ie /tmp/krb5cc_[uid]_[random] , but the file is not created. Testing with the patch (ie, pam_setcred(PAM_REINITIALIZE_CRED) ), KRB5CCNAME is set to /tmp/krb5cc_0 and that file is populated appropriately. The issue here being that it is obviously not a file linked to the user's [uid], and I could see that causing all sorts of issues. Will continue to debug this...
+*slim-1.3.4-r1 (05 Oct 2012) + + 05 Oct 2012; Ian Stakenvicius <axs@gentoo.org> -files/slim-1.3.3-config.diff, + -slim-1.3.4.ebuild, +slim-1.3.4-r1.ebuild, +files/slim-1.3.4-config.diff, + +files/slim-1.3.4-pam-end.patch: + force default vt07 (bug 436620) and ensure pam session isn't erroneously + cleaned during child execution (cause for krb5 ticket cache not existing in + bug 436556) +
I tried this latest ebuild and I can confirm that I now get my credentials through and the cache file is correctly named. Really big thank-you for sorting this out so quickly! Now, if something could be done to just get rid of that horrible moment during logout when the console is visible...
