[Bug 423] Workaround for pw change in privsep mode (3.5.p1)

Michael Steffens michael_steffens at hp.com
Fri Nov 8 01:16:01 EST 2002


Darren Tucker wrote:
> I'm still coming to grips with both PAM and privsep so correct me if I'm
> wrong here, but...
> 
> PAM uses a callback hook (ie the "conversation" function), right?
> This conversation function will get called several times, each time with
> one or more messages to handle?
> 
> PAM needs root, so the authenticating part has to be in the privileged
> monitor along with its callback. But the bits that drive the
> conversation with the user are in the unprivileged child. And privsep
> allows unpriv->priv calls but not vice versa?

That's how I do understand it (may be wrong). With privsep turned on

   auth_pam_password(Authctxt *authctxt, const char *password)

is called by the monitor. Arguments (in particular the password) have been
passed from the unprivileged daemon in the authentication request, before.

The function above calls do_pam_authenticate() after setting

   pamstate = INITIAL_LOGIN

which makes the conversation function do_pam_conversation() act "blindly",
i.e. reply to PAM using the given passord on every PAM_PROMPT_ECHO_OFF
style message, and obviously assuming that there will be only one.  Or,
more precisely, only one password, that PAM may prompt for arbitrarily
often.

The unprivileged daemon just gets success or failure returned. The user
doesn't see any messages generated by PAM on authentication. Even the
prompt, like

   dummy at localhost's password:

is generated by sshd, rather than PAM.

And, if the PAM stack for sshd is really configured to prompt for
multiple different passwords, authentication will always fail...

Ooops! Hadn't thought about the last point yet.  But at least the password
*change* helper would already be prepared to handle such a setup afterwards,
if it had a chance to get called :)

And even if it's only about a single passwords, it does add value by handling
arbitralily "odd" dialogs.

> So you need to break the conversation function into two pieces with some
> kind of polling? Ugh, this makes my head hurt.

So it did with mine...




More information about the openssh-unix-dev mailing list