openssh unix dev - Jun 2002 - why fd passing?

If I understand privsep correctly, and I'm not sure I do as there
are some ambiguities in the illustration of what processes are
doing what, there is a way to avoid doing fd passing.  What I see
is that fd passing is done to send the PTY to the user privileged
process after the monitor process was requested to set one up.
Why not go ahead and have the monitor set one up before it forks
the child?  If it is already know that the child won't need one,
then it doesn't have to be done.  But if that isn't know at fork
time, go ahead and set one up and then if the user privilege child
decides it does not need one, it can just close the descriptors.
The needless resource usage should be very brief.  As long as the
closing of the descriptors properly releases the resource to be
re-usable again, all should be OK.

There might also be descriptor passing to send the network fd back
to the privileged monitor after the unprivileged process authenticated
the connection so that it can be passed to the user privilege child.
If this is the case, I'd think the monitor could just hang onto that
descriptor, but not select it for anything.  Then it can let the user
child inherit it, and close it at that time.

I do not see from this illustration how mmap() is involved.

-- 
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/     |
-----------------------------------------------------------------

On Wed, Jun 26, 2002 at 11:46:24AM -0500, Phil Howard
wrote:
> Why not go ahead and have the monitor set one up before it forks
> the child?
with protocol 2 multiple pty and multiple login
shells over one connection are allowed.
the ssh.com windows clients supports this for
example.
> I do not see from this illustration how mmap() is involved.
it's used for passing the internal zlib compression
state around.

-m

Phil Howard <phil-openssh-unix-dev at ipal.net> writes:
> then it doesn't have to be done.  But if that isn't know at fork
> time, go ahead and set one up and then if the user privilege child
> decides it does not need one, it can just close the descriptors.
This doesn't work - the client may request a shell service at any
point, so you'd have to keep the pty ready-to-use for the entire
session. 
> I do not see from this illustration how mmap() is involved.
AIUI, the shared memory is for zlib use.

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org