IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Who has the ball for subsystem startup



[WRT draft-ietf-secsh-connect-09.txt and recent comments.  -- ksb]


I know I'm not a regular speaker here, I just lurk a lot.  Take my views for
what they are worth.


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 subsystem lets the implementor of the secsh service pick
	  the program to run.

So a `subsystem' I view more like a well known service that is provided to
the client *without* need for the client side to know the server side details
of how it is executed.

So the specification should say exactly that.  We send the name of the
subsystem we want, the server finds it and starts it.  All this talk about
filtering output from the startup of the subsystem is misplaced -- the server
implementation has to manage that startup because we (the client) don't know
how it happens.


> restriction, e.g. a user is allowed to send request only for this
> and that subsystem.

We have a way to limit what a login can run on any system I've ever used (be
it UNIX's rwx, PC physical access, or RACF rules).  We don't need to create
another: clients can ask for a subsystem by name and the server can check
with the (already negotiated) credentials.



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.

But the point is that the specification should not force the client to filter
for any cookie in any case -- it should be contained to the server's startup
code because the server "has the ball" for subsystem startup.

--
ksb



Home | Main Index | Thread Index | Old Index