Re: X forwarding

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

On Mon, Apr 19, 2004 at 01:44:16PM -0400, der Mouse wrote:
> To request X forwarding, the client sends
> 
>      byte      SSH_MSG_CHANNEL_REQUEST
>      uint32    recipient channel
>      string    "fixed-x11-req%rodents.montreal.qc.ca@localhost"
>      boolean   want reply
>      uint32    token
>      uint32    x11 screen number

If all the server has to do is repeat the token then what difference
does it make?  Does it help the server keep track of forwarded displays?
Does it work like a generation number for when local display listeners
are re-used?

> The server is, yes, expected to take appropriate steps (some form of
> authentication at least as strong as MIT-MAGIC-COOKIE-1) to ensure that
> only authorized processes use the connection.
> 
> There is no single-connection boolean; that struck me as unnecessary
> complexity, and if the client wants those semantics, it can cancel the
> forwarding (see below) and reject any extra CHANNEL_OPENs that arrive
> because of the race or because the server rejects the cancel.

This makes sense, yes.

> The token is entirely opaque to the (ssh) server; the only things the
> server ever does with it are (a) send it back when an X connection is
> opened and (b) compare it when cancelling X forwarding.

See above.

> Upon getting a forwarded X connetion and its passing whatever security
> checks, the server generates
> 
>      byte      SSH_MSG_CHANNEL_OPEN
>      string    "fixed-x11%rodents.montreal.qc.ca@localhost"
>      uint32    sender channel
>      uint32    initial window size
>      uint32    maximum packet size
>      uint32    token from the corresponding CHANNEL_REQUEST
>      byte[6]   first six bytes of the client X setup packet (the byte
>                 order and version numbers)

What good does this byte[6] field do?  It doesn't really help the
client, since it's going to see those first 6 bytes in the channel data
stream anyways.  It can always forcefully close an x11 channel that it
did accept, if it doesn't like it.

>      string    connection method ("tcp" for TCP, others not yet
>                 specified - I'm imagining things like "decnet" and
>                 "local" for DECnet sockets and /tmp/.X11-unix/* - see
>                 below for more on this).
>      connection-method-specific data
>      for method "tcp":
>          string    originator address (e.g. "192.168.7.38")
>          uint32    originator port

What sorts of decisions do you expect a client to make based on this
information (which, after all, the client has to trust the server to be
honest about)?

I figure most clients will want to force local vs. non-local display
opens on the server, so why not just ask for this in the request
(e.g., through a boolean field)?

What about multiply-forwarded display?  How could the server know?  Does
it matter?

I think a "local-only" boolean in the client's x11 request ought to
suffice.  Or, to more closely match the tcpip-forward request, let the
client specify a display name pattern to use on the server side.

> The initial client->server setup packet is not carried as channel data;
> the first six bytes of it are carried in the open request with the rest
> being synthesized locally by the client.  In the Xserver->Xclient
> direction, the channel carries pure X data right from the beginning of
> the Xserver's response, but in the Xclient->Xserver direction, the
> first channel data consists of the client's first request, if any.

See above.

BTW, the terms "client" and "server" are very confusing here.  We need
to keep X11 display client/server and SSHv2 client/server terminology
straight.  SSHv2 servers here are X11 clients and SSHv2 clients are
proxies to X11 display servers.

> In general, I don't like ssh's dependence on something TCP-like in the
> protocol (for example, it assumes that the protocol has something like
> port numbers that can fit in a uint32, and it thus is not possible to
> run ssh, as defined, over DECnet stream sockets).  Since I didn't want
> to redesign the whole protocol, I've lived with this in most respects.
> But since I'm designing a new request for X, I wanted to fix at least
> that much of it, especially since the connection in question is
> entirely out of ssh's purview.  (This also addresses the question I saw
> in the archives about "what originator info do I use for an AF_LOCAL X
> connection?").

See above.  I'd rather not have any of this in the channel open request.
I think all any client will end up caring about will be the security of
the forwarded display, not where connections to it come from but how.

> I have not actually implemented cancelling X forwarding.  Here's a
> first stab at it:
> 
>      byte      SSH_MSG_CHANNEL_REQUEST
>      uint32    recipient channel
>      string    "cancel-x11-req%rodents.montreal.qc.ca@localhost"
>      boolean   want reply
>      uint32    token
>      uint32    x11 screen number
> 
> This cancels all previous X forwardings for that channel, token, and
> screen number.  I see no need for a way to wildcard any of these; if
> others disagree, two additional bits (to indicate wildcarding of the
> token or screen number) could be added, either as two booleans or as a
> uint32 flags bitmask....

Can there be more than one X11 display forwarded per-session channel?  I
don't think so... but then, maybe that's just because in the *nix world
there's only one DISPLAY environment variable per-process pointing to
one display only So don't worry about wildcarding.

See above about the token.

Nico
--