sys-auth/pambase-20100723 USE="consolekit cracklib kerberos sha512 -debug -gnome-keyring -mktemp -passwdqc (-selinux) -ssh" and sys-auth/pam_krb5-4.3 results in: Jul 23 18:36:31 zptr-nb01 login[5108]: pam_krb5(login:auth): user testuser authenticated as testuser@CAF.COM.TR Jul 23 18:36:31 zptr-nb01 login[5108]: pam_krb5(login:auth): user testuser authenticated as testuser@CAF.COM.TR Jul 23 18:36:31 zptr-nb01 login[5108]: PAM bad jump in stack Jul 23 18:36:35 zptr-nb01 login[5108]: FAILED LOGIN (1) on '/dev/tty2' FOR 'testuser', Permission denied and will not let me login. Changing (in /etc/pam.d/system-auth): auth [success=1 default=ignore] pam_krb5.so ignore_root try_first_pass to auth sufficient pam_krb5.so ignore_root try_first_pass i.e. adding new_authtok_reqd=done to the default config lets me login again. I am not sure why you preferred [success=1 default=ignore] i/o sufficient. Something I am missing? Why two auth...pam_krb5 lines in pam.d/system-auth? Also, using minimum_uid=1000 instead of ignore_root should be better security wise for pam_krb5 (in case a kerberos principal has the same name as a system account). Wouldn't it be better (for general consumption): auth sufficient pam_krb5.so minimum_uid=1000 auth required pam_unix.so try_first_pass nullok_secure [...] session optional pam_krb5.so minimum_uid=1000 session required pam_unix.so [...] account required pam_krb5.so minimum_uid=1000 account required pam_unix.so [...] password required pam_unix.so password required pam_krb5.so use_authtok minimum_uid=1000 or password sufficient pam_krb5.so minimum_uid=1000 password required pam_unix.so try_first_pass Why make it needlessly diffificult for the user with [success=1 default=ignore]? pam_krb5 is nice and good but its use case is limited. I am afraid a lot of people will inadvertantly turn it on. We should at least make it easy on them. Reproducible: Always
Sufficient will skip over other limitations, I'll check why it's reporting bad jump, as it works here, but it might be different setup. [success=1 default=ignore] simply means that pam_krb5 acts in the stead of pam_unix if it succeeds or it is ignored altogether if it fails, which is exactly what one would do... My reason for not using the minimum_uid option is that Gentoo still _lacks_ a standardized user id ripartition so I'd rather not consider anything in particular there.
It is just too complicated and too fragile, e.g. skipping over pam_unix with success=1. It is best left to sysadmin to decide how to handle kerberos auth. Keep it simple (see above) and let him/her decide according to local security policy. Average *nix user will not (should not?) be using pam_krb5 anyway. Final decision is yours, of course. I am mostly trying to learn.
(In reply to comment #1) > My reason for not using the minimum_uid option is that Gentoo still _lacks_ a > standardized user id ripartition True. But I still think a more secure default is warrented here. Sysadmin can change the default. To sum up, I feel that in the sys-auth/pam_krb5 case, our job as developers is to give sysadmins simple and sane defaults and perhaps nudge them gently to what we feel is best. But I expect that all users of pam_krb5 will be looking around under pam.d/ and making the necessary changes according to local policy. Sorry for the bug spam.
I fixed the login error... as for the sysadmin vs defaults, I'd say that having it working out of the box for the most stupid case should probably be enough. Most sysadmins would still set up PAM by themselves rather than get it defined by pambase, but it's a start at least, I'd say...
