Re: fds beyond 0/1/2

[Nicolas Williams <Nicolas.Williams%oracle.com@localhost>]

On Wed, Aug 25, 2010 at 11:32:11AM -0400, der Mouse wrote:
> >> I've got some ideas I can write up and float for comment.
> 
> Here's what I have.  Comments are invited.

I like the idea, though I'd like to see how it'd be used from a typical
Unix command-line.  I'm guessing something like a CLI option to list
file descripto numbers to forward, something like "ssh -r 0,1,2,5,7 ..."

> As a global request, fd-forward may be sent only by the client.  It is
> used to enquire whether the server supports this protocol.  In this
> use, it MUST have want-reply set true and MUST have zero bytes of
> request-specific data; servers supporting the protocol described here
> MUST respond to such a request with with SSH_MSG_REQUEST_SUCCESS and
> zero bytes of response-specific data.  Global requests with want-reply
> false and/or nonempty request-specific data are reserved for future
> specification; servers MUST respond to any such with
> SSH_MSG_REQUEST_FAILURE.  Clients MUST respond to any fd-forward global
> requests with SSH_MSG_REQUEST_FAILURE, regardless of want-reply and
> associated data.

Why is a global request needed?

> As a channel request, fd-forward may be issued by the client on any
> channel of type "session" which has not yet had an "exec" or "shell"
> request (or any other requests of similar semantics - collectively,
> exec-style requests) made on it.  (moussh implements no exec-style
> requests other than standard exec and shell requests as of this
> writing.)  It also MUST have want-reply set true.  Using it in
> violation of any of these requirements (on a channel of any other type,
> on a "session" channel which has had an exec-style request made on it,
> or with want-reply false) is reserved for future specification and MUST
> draw SSH_MSG_REQUEST_FAILURE.  The server may also issue fd-forward
> channel requests, but only as outlined below, in response to
> client-issued fd-forward channel requests; other use in the
> server->client direction is similarly reserved and likewise MUST elicit
> SSH_MSG_REQUEST_FAILURE.  The same is true of requests in either
> direction which meet the above criteria but carry request-specific data
> (or lack thereof) violating the syntax below.

I agree with the design based on a channel request.

Nico
--