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

[Darren Tucker]

This raises another possibility for changing passwords.

As I see it the options now are:

1) Platform specific functions
Pro: RFC compliant
Con: extra code that runs as root

2) Spawn /bin/passwd in session
Pro: Simple, portable
Con: Not RFC compliant, possible timing attacks against proto 2?

3) Platform-specific setuid helpers
Pro: Consistent v1 & v2 interface, delegate policy to user-written
helpers, RFC compliant.
Con: Potential attacks against setuid programs, repeated code (eg
command line parsing).

4) Spawn /bin/passwd in tty (ala "expect")
Pro: portable? RFC compliant.
Con: lots of code, hard to get right, potentially flakey

I know Markus doesn't like 1) and says that the only portable thing to
do is 2). Isn't this similar the the case for UseLogin? After all the
only portable way to do user authentication is /bin/login, but UseLogin
defaults to no and is considered depreciated, right?

I'm still in favour of 1). 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). The
rest of the patches are required to check whether or not a password is
expired regardless of which method is used to change it.

Regarding 3): if a consistent enough interface was specified you could
use the same setuid helper for PASSWD_CHANGEREQ during proto 2
authentication as well as proto 1 sessions.

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)?
Or is some odd PAM module likely to render that impossible?

[0] See list archives or http://www.zip.com.au/~dtucker/openssh/

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