openssh bugs - Aug 2004 - [Bug 918] ssh_gssapi_storecreds called to late to be usable by PAM in sesion.c

http://bugzilla.mindrot.org/show_bug.cgi?id=918

           Summary: ssh_gssapi_storecreds called to late to be usable by PAM
                    in sesion.c
           Product: Portable OpenSSH
           Version: -current
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: PAM support
        AssignedTo: openssh-bugs at mindrot.org
        ReportedBy: deengert at anl.gov


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.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=918





------- Additional Comments From deengert at anl.gov  2004-08-24 00:39 -------
Created an attachment (id=701)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=701&action=view)
move call to ssh_gssapi_storecreds in session.c before call to PAM




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=918





------- Additional Comments From djm at mindrot.org  2004-09-11 19:09 -------
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?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=918





------- Additional Comments From dtucker at zip.com.au  2004-09-11 20:02 -------
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"




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=918





------- Additional Comments From dtucker at zip.com.au  2004-09-11 20:14 -------
(From update of attachment 701)
>+#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).




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=918

dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #701 is|0                           |1
           obsolete|                            |



------- Additional Comments From dtucker at zip.com.au  2004-09-11 20:16 -------
Created an attachment (id=713)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=713&action=view)
Fix tabbage.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=918

dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
    Attachment #713|                            |ok
             Status|                            |



------- Additional Comments From dtucker at zip.com.au  2004-09-11 20:17 -------
(From update of attachment 713)
FWIW this seems OK to me, assuming there's a good reason for calling it
twice.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=918





------- Additional Comments From djm at mindrot.org  2004-09-11 20:25 -------
I think it is there twice for the HAVE_LOGIN_CAP case. 



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=918





------- Additional Comments From dtucker at zip.com.au  2004-09-11 20:37 -------
Ah, yes, that would be it.  One of these days I'll learn to read the ifdefs
properly...



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.