[PATCH] Password expiry with Privsep and PAM

[Peter Stuge]

On Wed, Dec 11, 2002 at 10:24:34AM +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:

I'll try to hack something up.  Can I use regexec()?  *grepping*..  No regex
mentioned.  Just sscanf() or maybe even strcmp() then.  :)


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

Well, yes, of course an expect like system is required.  But the passwd chat
is very simple, either the password change succeeds or fails.  And more
importantly the only unknown data ever to be sent to passwd is the old and
the new password, both received from the client.

This system could optionally be combined with uname information to make sure
similar systems never get mixed up, on the other hand without uname it might
magically work for new vendor xyzzy too if they're using the same labels as
someone else.

Handling the trusted HP-UX example above would go like this:

expect "to pick your passwords (p) ?"
send ""
expect "Enter choice here:"
send "p\n"
expect "New password:"
send new_password "\n"
expect "Re-enter new password:"
send new_password "\n"
expect "Passwd successfully changed"

And if anything fails along the way, touch luck, the SSH protocol has no way
to propagate messages such as "Password must contain..." back to the client.
sshd just sends back SSH_MSG_USERAUTH_CHANGEREQ* and starts over waiting for
another SSH_MSG_USERAUTH_REQUEST from the client.
I'm even tempted to use a fixed 256 char buffer for the expect function.  :)

Note that the old password always needs to be verified first, before trying
to change it, if that fails a special error message is returned to the
client.  But since this is done in other places I'm sure it'll be easy to
add within or outside the passwd chat system.

* This might be a typo in the draft, I guess it should be _USERAUTH_PASSWD_.


> > 1. openssh implements all neccessary local password changing stuff
> > 2. openssh uses passwd because of law of least resistance, this is the
> 
> Having had a go at implementing both, I think (2) will end up bigger,
> uglier and flakier that the sum of (1).

I will try to prove you wrong.  :)


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

Since we already have a powerful control language (C) I doubt the neccessary
code would end up being more than a few KB even uncompressed..  Your very
expect_fd() only needs some buffering stuff to allocate memory until match
found or end of buffer..

Also we'll benefit from the fact that (sorry for repeating myself) the user
running the client isn't expected (mind the pun) to see any of the
conversation, much less interact.

I'll whip something up.


//Peter