Re: last-call issues..

[nisse%lysator.liu.se@localhost (Niels Möller)]

Jason R Thorpe <thorpej%zembu.com@localhost> writes:

> On Wed, Mar 14, 2001 at 12:12:57PM +0100, Markus Friedl wrote:
> 
>  > the server implementing sftp can print what ever cookies
>  > it likes and the sshd has to filter the cookies out.
>  > but this is not a _protocol_ issue.
> 
> Hm, this doesn't really strike me as good design -- if we all agree that
> subsystems require only a bi-directional stream communication channel,
> then it seems like a cop-out to rely on some special in-band-but-filtered-out
> communication between the sftp server and the transport server.

It relies only on a clean bi-directional stream. If you have that (as
is usually the case), none of this cookies-and-filtering stuff is
needed at all. The problem is that on systems where both of the
conditions below are true,

 * Subsystems are implemented as external programs that are exec:ed
   via the user's login shell.

 * The shell startup scripts, either system global scripts or the user's
   personal scripts, are broken and send some random junk to the shell's
   stdout.

the connection between the ssh server and the sub-system server is
*not* a clean stream, it is polluted. Tero and others that advocate
cookies believe that it is important that the protocol works even in
this case, where you don't have a clean and tidy channel. There are
several possible solutions for cleaning it up:

1. Don't start the login shell, just exec the sub-system server
   directly. I think the convention to use the login shell is peculiar
   to unix. Tero seems to believe that VMS and mainframes have similar
   problems, I don't know but that sounds quite unlikely to me.

2. Fix the scripts. You'd want to do that anyway, a .bashrc that
   writes to stdout is utterly broken and may cause all sorts of
   trouble.

3. Let the server tidy up, by looking for some data that resembles the
   real sub-system protocol data, and filter out everything before that.

4. Require clients to perform the same filtering.

Tero seems to argue that (4) is the preferable solution. I think (2)
is the only good solution, and if that for some reason is impractical,
I'd choose between (1) and (3) (or other local tricks like the fd juggling
that someone else proposed). I.e. solve the problem locally.

Pushing a server side configuration error over to the clients to deal
with seems wrong.

And for *all* the solutions but (1), it's *still* possible for both
users and sysadms to screw things up by writing stuff in the shell
startup scripts. Consider this .bashrc:

  #! /bin/bash
  
  (sleep 17; echo "I'm alive!") &

/Niels