Hi, Cross-posting to openssh-unix-dev and xorg-devel because this concerns both projects. When X11 connection is forwarded using ssh, the ssh client typically connects to the local X server using unix socket (often it is the only option because X servers no longer listens on TCP by default). X clients connected remotely over ssh then seem like if they are local to the X server. Because of that it will attempt to use extensions that are meant for local clients only (SHM, DRI*, etc). In most cases the client or server can detect failure and fallback to a method that works remotely, but this does not always work: https://bugzilla.opensuse.org/show_bug.cgi?id=1022727 (comments 24-26) In case of DRI3, X server tries to pass file descriptor to the X client. That works over the unix socket between X server and SSH client, but of course can not be sent further over network. There is no way failure can be detected and the communication gets stuck forever. The ideal solution would be if ssh marked the connection as remote. X protocol supports that since 2011: https://cgit.freedesktop.org/xorg/xserver/commit/? id=e2c7d70e5ddb8b17676a13ceebfbb87d14d63243 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. Best regards, Michal Srb -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Mark-x11-connection-as-remote.patch Type: text/x-patch Size: 1165 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20171002/719eaed1/attachment.bin>
Michal Srb wrote:> In case of DRI3, X server tries to pass file descriptor to the X > client. That works over the unix socket between X server and SSH > client, but of course can not be sent further over network. There > is no way failure can be detected and the communication gets stuck > forever. > > The ideal solution would be if ssh marked the connection as remote.Not forwarding/proxying also the fd to the remote SSH client? //Peter
On pond?l? 2. ??jna 2017 13:28:30 CEST Peter Stuge wrote:> Michal Srb wrote: > > In case of DRI3, X server tries to pass file descriptor to the X > > client. That works over the unix socket between X server and SSH > > client, but of course can not be sent further over network. There > > is no way failure can be detected and the communication gets stuck > > forever. > > > > The ideal solution would be if ssh marked the connection as remote. > > Not forwarding/proxying also the fd to the remote SSH client?I am not sure what you are suggesting. The SSH client runs on the same machine as X server and it connects to it using the unix socket. From X server's point of view, the SSH client looks just like any other local X application. Except the fact that features like SHM and file descriptor passing does not work. Even worse, the file descriptors are passed successfully but then ignored. X server can work with both local and remote clients, but not with remote clients that pretend to be local. SSH should mark the connection as remote, so X server knows to not attempt things that can not work remotely. Maybe we could find some workaround that would allow the X server to recognize this specific case (DRI3 fd passing), but it is just matter of time when some new thing fails. Michal Srb
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. -d
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