Re: Who has the ball for subsystem startup

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

K S Braunsdorf <ksb%sa.fedex.com@localhost> writes:

> Using a `subsystem' must be different than remote execution of a shell
> command -- because we already have a way to do that.  In section 4.5 we
> either start a shell, an exec, or a subsystem and I think I see why we
> want each:
> 	+ the shell lets the service indirect though a local mechanism
> 	  to pick the program to run,
> 
> 	+ the exec lets the client (implementor or user) pick the program
> 	  to run,

The difference is probably smaller than you think. If SHELL is the
user's login shell, typically

  "shell" means execl(SHELL, SHELL, NULL)

  "exec" means execl(SHELL, SHELL, "-c", COMMAND, NULL)

So in _both_ cases, the login shell and its $PATH is involved. And it
more or less has to be, if you want to support sending a command
_line_ to the server.

Hmm, the spec doesn't say explicitly that command is a command line,
but I believe that is what is intended. I.e. "grep foo
/var/log/messages | sort" is a reasonable command to use with exec. In
a less platform-specific way, I think one could say that a command
that is reasonable for system() on the server platform is also
reasonable for the "exec" request .
 
> 	+ the subsystem lets the implementor of the secsh service pick
> 	  the program to run.

The implementor can also choose to implement it as a part of the same
server. Of course, it's _possible_ to look at the command line for
"exec" and recognize some commands to be implemented internally, but
it is a lot cleaner to do that with "subsystem" than with "exec". I
think that is the main justification for "subsystem".

> I really don't like the hack of trying to put a cookie in the output stream;
> moving the file descriptors (or similar) is a much more sane tactic.  I don't
> think we should put the burden on the client to make up for poor server
> implementations.

I agree completely.

/Niels