Re: last-call issues..

[Simon Tatham <anakin%pobox.com@localhost>]

Tero Kivinen <kivinen%mail.niksula.cs.hut.fi@localhost> wrote:
> As the user's shell might be used to execute the subsystem, it is good
> subsystem protocol design to include a "magic cookie" at the beginning
> of the protocol transaction to distinguish from arbitrary output from
> shell initialization scripts etc.

This is a horrifyingly ugly way to separate subsystem output from
startup script output; not only is it ugly, it's also fragile. Why
not do it the ordinary way, by means of using different file
descriptors?

Here's a Unix implementation sketch, which is roughly similar to one
I already suggested to the OpenSSH people (but marginally more
coherent in details):

 - When invoking a subsystem, _don't_ open pipes on the child
   process's stdin/stdout. Instead, open pipes on some _different_
   fds passed to the child. Open /dev/null on the child's stdin and
   stdout.

 - The user's login scripts now run, and if they generate any output
   at all it goes to /dev/null.

 - The command you pass to the user's login shell is not
   `subsystem-program'. Instead, it's `subsystem-wrapper <rfd> <wfd>
   subsystem-program', where subsystem-wrapper is a small helper
   program (in /usr/lib, say). <rfd> and <wfd> are the file numbers
   of the pipes provided by sshd.

 - subsystem-wrapper first closes its stdin/stdout file descriptors.
   Then it uses dup2() to move the <rfd> provided on to fd 0, and
   move the <wfd> on to fd 1. Finally, it execs the real subsystem
   program.

So sshd ends up talking directly to the subsystem program, and vice
versa. Output from the init scripts automatically goes to /dev/null
and doesn't ever need to be filtered out of the same stream.

Best of all, the subsystem program _itself_ doesn't need to change
in the slightest. It still reads and writes on its stdin and stdout,
so it's still easy for people to write custom subsystems.

(It could be argued that if the user's startup scripts do anything
really interesting involving opening extra fds in the shell, this
mechanism might still blow up. Even more robust would be to open
named pipes in an appropriately secured subdirectory of /tmp, and
pass the names of the pipes to subsystem-wrapper.)

I think that, given the existence of properly robust solutions like
this, it's inelegant to suggest that implementors should use as
fragile a mechanism as magic cookies.

Cheers,
Simon
-- 
Simon Tatham         "Thieves respect property; they only wish the property to
<anakin%pobox.com@localhost>    be their own, that they may more properly respect it."