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

Darren Tucker dtucker at zip.com.au
Fri Nov 8 00:08:17 EST 2002


Michael Steffens wrote (in 2 separate messages):
>  > The platform-specific change functions that
>  > I've done so far[0] are ~40 lines (AIX) and ~100 lines (/etc/shadow).
>  > The shadow function handles 3 platforms (Solaris, Redhat, UnixWare).
> 
> This is only true for Solaris and Redhat (don't know about UnixWare)
> if sshd is not configured to use PAM for authentication! Otherwise it's
> calling for mismatches.

Good point. It should include "#if !defined(WITH_PAM)".
UnixWare apparently has shadow but no PAM.

>  > Also, can someone who knows PAM please tell me if it's feasible to
>  > implement a function like:
>  > pam_change_password(char *user, char *oldpass, char *newpass)?
[snip]
>     I would say it's impossible to encapsulate such dialogs using
>     a function like you are suggesting, unless you restrict
>     to option (p), and prepare for being presented the choice,
>     of course.

That pretty much makes the general case for PAM incompatible with the
password change part of the SSH2 userauth-password protocol. The client
sends a USERAUTH_REQUEST with the change password flag set, followed by
old and new passwords. (This may or may not be after a
USERAUTH_CHANGEREQ from the server.)

Frank Cusack mentioned keyboard-interactive.. it looks like it's time to
RTFRFC again.

> But if it does only work with privsep off I would assume it
> doesn't do conversation tunneling between session daemon
> and monitor, because there is no monitor?

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?

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

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.



More information about the openssh-unix-dev mailing list