Password expiry patch plans

[Darren Tucker]

The patches I've been working on are an experiment. I don't expect it to
be merged as-is. Some parts might work out OK and get merged, some
probably won't. I don't decide which, if any, do but I hope that
password expiry ends up working on most supported platforms that have
the capability.

There's several things being traded off here: code size, complexity,
portability and (expired draft) RFC compliance.

Michael Steffens wrote:
> Isn't that adding just another kludge, where we already do have
> an expample where it won't work in default configuration?

Yep. We'll also have many (the majority?) of configurations where it
will and where it works it'll be RFC-compliant for PASSWD_CHANGEREQ.
Many people just want expiry to work and don't want to do anything
tricky with PAM.

[snip]
> I doubt this was the only
> opportunity you might get trapped by unexpected conversation
> behaviour of password change dialogs.

Those cases could use something else (keyboard-interactive, /bin/passwd
or the setuid helper in the session).

> Why /bin/passwd also for PAM?  What's wrong with the helper
> dedicated to "sshd" service?

Because I've already copped flak about the size of the patch and it's
not needed for the experiment. It does roughly the same thing as
/bin/passwd and can be considered independantly.

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

Agreed.

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