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

bugzilla-daemon at mindrot.org bugzilla-daemon at mindrot.org
Tue Mar 11 23:13:34 EST 2003


http://bugzilla.mindrot.org/show_bug.cgi?id=423





------- Additional Comments From dtucker at zip.com.au  2003-03-11 23:13 -------
Actually, the first proposal (ssh-chauthtok-helper) by Michael Steffens does not 
require monitor calls by the shell child.  It wasn't very popular, though.

The current architecture requires a change after the tty is established in the 
shell child, which has already setuid to the user.

Assuming that it must be done that way (to support protocol 1), changing the 
password may require privs, and the shell child can't *call* the monitor, some 
possible options are:

1) A setuid helper (ssh-chauthtok-helper, /bin/passwd), eg,
if (use_privsep)
    exec /bin/passwd
else
    do_pam_chauthtok()

2) Have the monitor fork a child *that does not exit immediately* and return a 
descriptor connected to it.  Have that child wait for a write on the descriptor.  
When the shell child runs, it writes to the descriptor to wake up the privileged 
child which runs do_pam_chauthok(), using a little protocol to indicate success 
or failure.  This is fiddly and complex (== bad) but might work.

Since there's always *someone* who hates a given solution to this problem, I 
vote for 1) with /bin/passwd.  It's simple and I've already written most of it 
:-)

The PAM purists will hate it but they can turn off privsep if they need the real 
do_pam_chauthtok, or re-define PATH_PASSWD_PROGRAM and make it run whatever they 
like.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.




More information about the openssh-unix-dev mailing list