The gss-serv-krb5.c will call do_pam_putenv to set the KRB5CCNAME so it can be used by a PAM routine. But the call to ssh_gssapi_storecreds is called from do_exec which is way to late to be usable by do_pam_session or do_pam_setcred. Suggestion is to move the call.
Created attachment 701 [details] move call to ssh_gssapi_storecreds in session.c before call to PAM
I don't understand: ssh_gssapi_storecreds() is currently called in do_exec(). The flow then goes do_exec()->do_exec_pty()->do_child()->do_setusercontext(). The PAM calls happen in do_setusercontext() and ssh_gssapi_storecreds() has therefore already been called. What am I missing?
sshd.c calls do_setusercontext() to set up the post-auth privsep credentials, and do_setusercontext has the pam_setcred() calls. The second call to do_setusercontext in session.c is a no-op for the privsep case (ie if uid != 0 && euid != 0). I whacked some debugs in at the #ifdef GSSAPI points and gssapi_storecreds(), the interesting bits are: debug3: PAM: opening session debug2: User child is on pid 5313 debug3: mm_request_receive entering debug1: PAM: reinitializing credentials debug1: permanently_set_uid: 500/500 [...] debug3: GSSAPI: ssh_gssapi_storecreds() debug1: PAM: setting PAM_TTY to "/dev/pts/2"
Comment on attachment 701 [details] move call to ssh_gssapi_storecreds in session.c before call to PAM >+#ifdef GSSAPI >+ if (options.gss_authentication) { >+ temporarily_use_uid(pw); >+ ssh_gssapi_storecreds(); >+ restore_uid(); >+ } >+#endif BTW, the indenting is wrong (should be two tabs) and that's a bit misleading. Why is it called twice? (I'm guessing for the same reason PAM is: to re-establish supplemental groups, eg a PAG).
Created attachment 713 [details] Fix tabbage.
Comment on attachment 713 [details] Fix tabbage. FWIW this seems OK to me, assuming there's a good reason for calling it twice.
I think it is there twice for the HAVE_LOGIN_CAP case.
Ah, yes, that would be it. One of these days I'll learn to read the ifdefs properly...
Applied, thanks.
With the release of OpenSSH 4.0, these bugs are now closed. For details, see: http://www.openssh.com/txt/release-4.0