Re: X forwarding

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

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

It allows the (ssh) client to tell which forwarding request a given
forwarded X connection corresponds to (and, in particular, allows
determining which session it goes with - this is cruicial for making X
forwarding work with connection sharing).

>> 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's just the place I chose to put that data.  I'm not fanatical about
putting it there; if it would make you feel better you could put it at
the beginning of the channel data, perhaps even with four zero bytes
and two arbitrary bytes appended so the channel data stream is valid X
protocol in isolation (I can't really see why this would matter, but I
infer some such desire from your stating that the (ssh) client will see
them in the channel data stream despite my trying to clearly state that
that data blob is _not_ present in the channel data stream).

> It doesn't really help the client, since it's going to see those
> first 6 bytes in the channel data stream anyways.

I don't understand.  I wrote text (later) in which I tried to make it
clear that that data _isn't_ in the channel data stream; you even
quoted it, so you apparently read it.  Was I not clear enough?  Or do
you just find it so horrible a thing to contemplate that you cannot
even admit the possibility?  Or what?

> It can always forcefully close an x11 channel that it did accept, if
> it doesn't like it.

I don't include it for the client to see whether it likes it, but
rather because the (ssh) client has to get those bytes _somehow_.

>>      string    connection method ([...]).
>>      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)?

None in particular.  Why do you assume that making decisions based on
that information is the only reason to pass it?  I have no trouble
imagining the (ssh) client maintaining some kind of user-interface
display of forwarded X connections, in which case displaying where the
connection is from could be good.

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

I sure hope it doesn't matter, because I don't think it can know, at
least not for the TCP case.

> BTW, the terms "client" and "server" are very confusing here.

Yes.  I've been trying to indicate which is which when I think
confusion is likely, though I've doubtless missed some cases.

>>      string    "cancel-x11-req%rodents.montreal.qc.ca@localhost"
>> [...wildcarding...]

> Can there be more than one X11 display forwarded per-session channel?

The (ssh) client certainly can send more than one X forwarding request
for a session.  What happens if it does is a good question, especially
for OSes like most Unices that communicate X display information to X
clients via something which (like $DISPLAY) can't handle more than one
display - I suspect it would have to be left up to the implementation.
(My own implementation, as it stands now, rejects all but the first; I
may, when I implement cancels, allow a forwarding request whenever
there are no uncancelled forwarding requests on that session.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B