[PATCH] Password expiry with Privsep and PAM

[Darren Tucker]

Peter Stuge wrote:
> On Wed, Dec 11, 2002 at 06:50:36AM +1100, Darren Tucker wrote:
> > As Ben said, using /bin/passwd in v2's (pre-session) PASSWD_CHANGEREQ
> > requires writing expect-like functionality that would be very hard to
> > get right across all platforms.
> 
> Would it really?

In my opinion, yes.  Feel free to prove me wrong.  You might want to
start with my crude implementation of it:

http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=103598314323495&w=2

> Remember that this project has a lot of good people coming
> from different platforms.  Also keep in mind that the PASSWD_CHANGEREQ
> protocol is the single smallest denominator, severly limiting what needs to
> be supported.  I'm thinking all that can be expected is for sshd to handle
> cases where passwd wants either the old or the new password, sshd doesn't
> have any other information at that time and no real way to get any either,
> unless the protocol is extended, right?

I think you're underestimating the amount of weirdness out there hiding
in /bin/passwd. Consider this example from HP-UX in a trusted
configuration:

trustedhpux# passwd testuser
Changing password for testuser
Last successful password change for testuser: NEVER 
Last unsuccessful password change for testuser: Tue Dec 10 23:06:13 2002

Do you want (choose one letter only): 
        pronounceable passwords generated for you (g) 
        a string of letters generated (l) ?
        to pick your passwords (p) ?

Enter choice here: p
New password: 
Password too short - must be at least 6 characters
New password: 
Password must contain at least two alphabetic characters and
at least one numeric or special character.
New password: 
Re-enter new password: 
Passwd successfully changed

> Two scenarios become possible:
> 
> 1. openssh implements all neccessary local password changing stuff - PITA
> overhead but when done a lot lower "instance" overhead, the PASSWD_CHANGEREQ
> becomes more lightweight.  However, openssh might have to deal with vendor
> quux's broken system yet another time.
> 
> 2. openssh uses passwd because of law of least resistance, this is the
> simplest path to go.  When vendor xyzzy ends up having a passwd that
> requires more capabilities than sshd has while in PASSWD_CHANGEREQ they can
> either fix their passwd or try to convince us that we should switch to (1).

Having had a go at implementing both, I think (2) will end up bigger,
uglier and flakier that the sum of (1).

> Set up an easy scheme to add support for platforms with (2) and I think it'd
> happen pretty quickly.

What you're talking about is implementing a subset of "expect". For
comparison oldest, smallest expect I could find is still a couple of
hundred KB compressed.

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