Re: last-call issues..

[Jason R Thorpe <thorpej%zembu.com@localhost>]

On Wed, Mar 14, 2001 at 07:06:05PM +0100, Niels Möller wrote:

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

Possibly peculiar to current unix implementations.  Unix certainly
doesn't require a shell to intervene for programs started by e.g.
inetd(8).  I seems reasonable to me to do it this way, as well.  However,
read on :-)

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

Well, it's not clear that it's a "configuration error".  It could be
debugging information that the client could choose to display on the
user interface.

Let's take a broader look.  You say that SFTP requires a "clean
bi-directional stream", which is provided by a transport layer.
Well, really, the SSH protocol transport layer itself requires
the same thing -- it happens to be provided by TCP.

However, in the SSH transport setup, we allow "junk" to exist on
the "channel" (the TCP connection) up until the protocol version
exchange message, and it is the responsibility of the client to
cope with this.  While the transport document describes the intended
use of this feature, it doesn't *require* that it be the only use.

Now, since no one is arguing (as far as I can tell) that the transport
document should be changed in this regard, I personally see no reason
not to be consistent with it when dealing with subsystems.

Seriously -- in concept, what is *really* different from the transport
that the SSH transport protocol runs over and the transport (the SSH
transport) that a subsystem runs over?  Nothing!  They're both bi-directional
streams -- the latter happens to be secured.  If they're both conceptually
the same, then I think we should treat them the same way.

 > 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!") &

Sure, and you could have a buggy TCP implementation on the peer, as well
(say, which transmits garbage in one of the segments).  What happens in
that case?  The "channel" that the SSH transport runs on gets killed (by
the SSH transport implementation -- presumably, the MAC would fail,
or something).  If we get a bogus clump of data on the "channel" that
the subsystem is using, then the subsystem can kill the channel (by exiting,
for example) if it causes a protocol error for the subsystem.

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