openssh unix dev - Jan 2003 - Privsep question: can the slave's child make monitor calls?

Hi all.
	I have a question regarding privsep.  Firstly, the following is my
understanding of what happens when privsep is enabled:

	The sshd daemon is running as root listing on 22(a).  When a connection
is accepted, a child is forked to handle the connection, this child
becomes the monitor(b).  The monitor forks the pre-auth privsep
slave(c), which sheds it privs and hides in its chroot jail.  If the
user is authenticated, the pre-auth slave exits and the post-auth
slave(d) is forked. This slave sets its uid to the user's, does some
prep work, then forks a process to exec the shell(e).  This process sets
up its descriptors then execs the shell.

	The question is about (e).  Because it's a child of the post-auth
slave, it inherits the descriptor that talks to the monitor so it *can*
make monitor calls, but it should it?  Isn't that a potential race
condition if the slave and its child make monitor calls at the same
time?

	The reason I ask is that one of my patches does this to check for
successful password change.  This (or some other solution) is needed
because in some instances /bin/passwd does not set a failing return
code.

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

On Wed, Jan 29, 2003 at 06:24:12PM +1100, Darren Tucker
wrote:
> Hi all.
> 	I have a question regarding privsep.  Firstly, the following is my
> understanding of what happens when privsep is enabled:
> 
> 	The sshd daemon is running as root listing on 22(a).  When a connection
> is accepted, a child is forked to handle the connection, this child
> becomes the monitor(b).  The monitor forks the pre-auth privsep
> slave(c), which sheds it privs and hides in its chroot jail.  If the
> user is authenticated, the pre-auth slave exits and the post-auth
> slave(d) is forked. This slave sets its uid to the user's, does some
> prep work, then forks a process to exec the shell(e).  This process sets
> up its descriptors then execs the shell.
> 
> 	The question is about (e).  Because it's a child of the post-auth
> slave, it inherits the descriptor that talks to the monitor so it *can*
> make monitor calls, but it should it?
no, i think (e) should _not_ talk to the monitor.