On st?eda 4. ??jna 2017 5:53:15 CEST Damien Miller wrote:> On Mon, 2 Oct 2017, Michal Srb wrote: > > SSH only needs to change the first byte sent from X client to server > > to mark it as remote. SSH already modifies the whole first message > > (replaces authorization data), so changing the first byte is easy > > addition. > > > > I have attached patch that implements it. Please check it and consider > > adding it or something similar to openssh. > > Thanks - is this flag fully backwards-compatible? Is there a chance it > could cause problems on older X11 implementations? IMO most of the people > using X11 forwarding are likely using it to/from older systems.It is not fully backward compatible. Older X server that does not understand the 'R'/'r' flag will reject the client. The commit that added support for the flag is from 2011. It seems that first time it appeared in release was in version 1.14.0, which was in March 2013. In addition, the potential incompatibility is only between the SSH client and the X server. They are normally both running on the same machine. So in normal scenario the an issue would only happen if you would install pre-1.14.0 X server and newest SSH client *on the same machine*. The remote side where SSH server and X applications run can have any versions, it does not affect them. I can imagine situation where SSH-ing to an old machine and from there to a new machine could cause an issue. Not sure how important/supported such scenario is. The situation could be possibly improved by: * Adding a parameter that disables setting the remote flag. * Automatically reconnecting without the flag if X server rejected connection with it. Michal Srb
On Wed, 4 Oct 2017, Michal Srb wrote:> On st?eda 4. ??jna 2017 5:53:15 CEST Damien Miller wrote: > > On Mon, 2 Oct 2017, Michal Srb wrote: > > > SSH only needs to change the first byte sent from X client to server > > > to mark it as remote. SSH already modifies the whole first message > > > (replaces authorization data), so changing the first byte is easy > > > addition. > > > > > > I have attached patch that implements it. Please check it and consider > > > adding it or something similar to openssh. > > > > Thanks - is this flag fully backwards-compatible? Is there a chance it > > could cause problems on older X11 implementations? IMO most of the people > > using X11 forwarding are likely using it to/from older systems. > > It is not fully backward compatible. Older X server that does not understand > the 'R'/'r' flag will reject the client. The commit that added support for the > flag is from 2011. It seems that first time it appeared in release was in > version 1.14.0, which was in March 2013. > > In addition, the potential incompatibility is only between the SSH client and > the X server. They are normally both running on the same machine. So in normal > scenario the an issue would only happen if you would install pre-1.14.0 X > server and newest SSH client *on the same machine*. The remote side where SSH > server and X applications run can have any versions, it does not affect them.Well that's a bit reassuring, since if it was the converse (new SSH, old X11 clients) then that would be more problematic. Is it too late to make the DRI3 developers adjust their protocol to degrade gracefully? Is there any lightweight way (i.e. not requiring any X11 libraries) that the client could determine whether or not the server supports this flag? -d
On p?tek 6. ??jna 2017 4:47:06 CEST Damien Miller wrote:> Is it too late to make the DRI3 developers adjust their protocol to degrade > gracefully?I am not sure, but I think it would be already able to degrade if it was able to detect error. But from what I observed, after X server (successfully) sends the file descriptor, no more data gets thru. So the X client (application) just waits indefinitely.> Is there any lightweight way (i.e. not requiring any X11 libraries) that > the client could determine whether or not the server supports this flag?Probably the easiest would be to probe it. It could just send the initial request starting with 'r' or 'R' and observe whether X server accepts or rejects the connection. Michal Srb
On p?tek 6. ??jna 2017 9:40:31 CEST Michel D?nzer wrote:> On 05/10/17 07:47 PM, Damien Miller wrote: > FWIW, xserver >= 1.18.4 detects SSH connections via the client's process > name, treats them as remote and doesn't expose DRI3 on them.Oh, that's actually workaround that would be sufficient, I will backport it to SUSE's X servers. It would be still nice to solve it systematically by making ssh mark the connection as remote, but this makes it less critical. Michal Srb
Dear all, This thread began before I was on the list. I am wondering if it is relevant for my question re: why/how older versions of openssh recognized the X11forwarding "attribute" - and a better place to be posting. Using Putty (and an "external Xserver program") as well as a another "ssh client with built-in X11 service) and any version of openSSH prior to OpenSSH-7.2 the DISPLAY is automatically set to localhost:10.0 and x11 apps (e.g., xclock) work. OpenSSH-7.2 through OpenSSH-7.6 do not (changing the version of OpenSSH is the only change). If this is not related to this thread - please disregard this comment here. (I'll wait a day, and post again on my original thread). Thank you for your time and consideration. On 10/6/2017 9:52 AM, Michal Srb wrote:> On p?tek 6. ??jna 2017 9:40:31 CEST Michel D?nzer wrote: >> On 05/10/17 07:47 PM, Damien Miller wrote: >> FWIW, xserver >= 1.18.4 detects SSH connections via the client's process >> name, treats them as remote and doesn't expose DRI3 on them. > Oh, that's actually workaround that would be sufficient, I will backport it to > SUSE's X servers. > > It would be still nice to solve it systematically by making ssh mark the > connection as remote, but this makes it less critical. > > Michal Srb > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >