Password expiry patch plans

[Michael Steffens]

Darren Tucker wrote:
> [was Re: [Bug 423] Workaround for pw change in privsep mode (3.5.p1)]
> 
> Frank Cusack wrote:
> 
>>The PAM framework demands the type of exchange that
>>only keyboard-interactive offers.  The way the "password" authentication
>>method interacts with PAM is a kludge.
> 
> 
> After following this thread and thinking about this for a while, this is
> the current plan for my experimental expiry patch[0]:
> 
> 1) Add "int password_changereq" and "char *postauth_message" to struct
> Authctxt. This will allow elimination of a bunch of global variables (eg
> password_change_required, loginmsg) and some #defines, and allow the
> merge of some of the AIX & PAM specific code (eg in session.c). It will
> require the parameters of getpwnamallow and friends to be changed to
> authctxt and another monitor wrapper for is_password_change_required and
> maybe get_login_messages. Would anyone object to that?
> 
> 2) Write a pam_change_password function that uses do_pam_conversation in
> INITIAL_LOGIN (ie "blind") mode and plug it into auth_change_password.
> This should cover the majority of simple cases (ie basically the same
> cases that the existing auth_pam_password function covers for "password"
> authentication) and work with privsep.

Isn't that adding just another kludge, where we already do have
an expample where it won't work in default configuration?
HP-UX in trusted mode is one thing. Another one will be whether
you are being prompted for the old password at all, depending on
real and effective UID, and possibly on PAM_RUSER and PAM_RHOST.

When I did last testings Solaris behaved differently there than HP-UX
and Linux did, if the real UID was zero, which will always happen if
the user logging in is root himself. I doubt this was the only
opportunity you might get trapped by unexpected conversation
behaviour of password change dialogs.

> 3) Hack pam_chauthtok into keyboard-interactive for proto 2 to handle
> the tricky PAM cases the Right Way. It won't work with privsep (see 6)
> but apparently it doesn't now anyway. People requiring deep PAM magic
> can use that ("PAMAuthenticationViaKbdInt yes").
> 
> 4) Make the general case for proto 1 call /bin/passwd (including for
> PAM). Maybe look at the following later:

Why /bin/passwd also for PAM?  What's wrong with the helper
dedicated to "sshd" service? Would consider that at least a
little bit cleaner.

As far as privsep is concerned I'm getting the feeling that
Frank is right that all calls of PAM functions should be
moved to the privileged monitor. Possibly this could also
solve the auditing corruptions reported for Solaris?

But in any way it requieres tunnneling PAM conversation between
monitor and unprivileged child, and this seems to be far from being
an easy task. Already tried to wrap my had around it only
for the keyboard interactive case...