Le 09/02/2025 à 22:08, Vladimir Dergachev a écrit :
This reminds me of the difference between ssh -X and ssh -Y options,
maybe a look at ssh code will give you ideas.
Indeed, ssh has several tricks to make the X11 forwarding
with some restrictions between -X and -Y "... too many programs
currently crash in this mode ... "
(https://manpages.debian.org/bullseye/openssh-client/ssh.1.en.html#X)
The code is unfortunately too complex for my skill level :-(
https://github.com/openssh/openssh-portable/blob/85b3d68dd931416ede657f371f1d60cdc3a66f34/channels.c#L1300
But I still wonder why in my tests X clients get stuck waiting for the
server.
Best regards
Christophe
On Fri, 7 Feb 2025, Christophe Lohr wrote:
Hello,
Please excuse the naivety of my question; I'm trying to understand
how things work.
I try to forward a tcp X11 connection to the server's unix socket:
$ socat TCP-LISTEN:6001,fork UNIX-CONNECT:/tmp/.X11-unix/X0
Then I can use it:
$ DISPLAY=localhost:1 xeyes
It works well... but only for simple applications (xlogo xeyes xclock
xmessage xnest...)
Surprisingly, this does not works for more complex applications
(Xephyr wireshark ...)
These applications stop, seemingly waiting for an event that doesn't
come.
Increasing socat's verbosity level doesn't help me to understand, nor
does strace ltrace xtrace ...
Well, this seems relating to the MIT-SHM extension.
My assumption: If the server thinks the client is local (due to the
use of a unix socket), it activates the MIT-SHM extension without
further preliminary checks (and tries to send ancillary data
(shm keys or file descriptor?) via the unix socket?). Right?
As a workarround, I have to generate an "untrusted" xauth cookie.
Is there a better way?
(Note: I'm a fan of network transparency!
A next time we'll talk about vsock;-) )
Best regards
Christophe
