Regarding PAM_TTY_KLUDGE and Solaris 8...

[Ed Phillips]

On Thu, 25 Oct 2001, Darren Moffat wrote:

> Date: Thu, 25 Oct 2001 10:51:01 -0700 (PDT)
> From: Darren Moffat <Darren.Moffat at eng.sun.com>
> To: openssh-unix-dev at mindrot.org
> Subject: Re: Regarding PAM_TTY_KLUDGE and Solaris 8...
>
> >Does this make sense?
>
> All makes sense to me.

[...snip...]

> >Darren... is this true - if PAM_TTY is not set and the user needs to
> >change his password, will pam_sm_acct_mgmt() in pam_unix.so return an
> >error that sshd can detect and process?
>
> Nope, and I don't think it should either. The pam modules do not assume
> that a tty is present to do the prompting because your converstation
> function might actually be a GUI.

When sshd calls pam_acct_mgmt(), will the conversation routine
automatically get called if the user needs to change his password (to emit
something like "Your password has expired." (The conversation routine
doesn't actually do anything but "print" messages right?)?  After calling
the conversation routine, then pam_acct_mgmt() will return
PAM_NEW_AUTHTOK_REQD (or some other error to indicate what's wrong)?
Then, the right thing to do is have sshd either fetch the password and
call...  what? pam_chauthtok()?  In our case (non-interactive, no tty)
this is the point where sshd could send a failure notice to the client an
close the connection.

> It is up to the calling application and its' conversation function to
> deal with getting the information from the user.  If pam_acct_mgmt
> returns PAM_NEW_AUTHTOK_REQD and sshd isn't able to prompt the user for
> one (because it has no tty) then it has to make its own choice of what
> to do, it can continue and ignore it or it can display a warning or it
> can disconnect - it is upto sshd to choose what to do (it could use
> SSH_ASKPASS if it is available).

Okay, this seems to be at least part of the answer I'm looking for above,
but check me to see if I'm getting it right (it's been a while since I was
last neck-deep in this stuff)...

> >back and forth enough to confuse everybody?).  Maybe there could be a
> >PAM_OPEN_SESSION_BROKEN flag in config.h, which is defined by default, and
> >we could document which patch needs to be applied on Solaris in order to
> >avoid the problem and allow pam_open_session() to be called (with NO
> >PAM_TTY set).
>
> Please do not use that as the option name, instead say something that
> says what you are acutally doing - not caling pam_open_session when sshd
> doesn't have a tty.  pam_open_session on Solaris is not broken, it is
> just that without the patch the pam_sm_open_session in pam_unix assumes
> that it is only ever called with a valid PAM_TTY - that was a bug.

Sorry... I was just looking for something to differentiate from the old
PAM_TTY_KLUDGE. ;-)

How about PAM_NO_TTY_NO_SESSION?

	Ed

Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082
Systems Programmer III, Network and Systems Services
finger -l ed at polycut.nss.udel.edu for PGP public key