Regarding PAM_TTY_KLUDGE and Solaris 8...

[Nicolas Williams]

On Thu, Oct 25, 2001 at 03:51:17PM -0400, Ed Phillips wrote:
> 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

For that message, yes, the conv function only prints it, though in a GUI
environment it would bring up a dialog with an "Ok" button.

> 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)

The right thing to do is to call pam_chauthtok() and let *it* do any
additional conversing with the user that might be needed.

For non-interactive sessions such conversing should/might not be
possible, thus the conversation would return an error to the modules
calling it, which would, depending on the modules and how the PAM
stack is configured, cause pam_chauthtok() to return an error back to
the application, which would then return an error to the user (i.e.,
sshd would close the connection to the client).

> 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)...

Again, it is not ok to just go on if pam_acct_mgmt() returns
PAM_NEW_AUTHTOK_REQD -- pam_chauthtok() must be called *and* it must
return PAM_SUCCESS or the session must be ended.

> 	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


Cheers,

Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.