Is there anything missing when forwarding my X11 connections?

[Christophe Lohr]

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
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg/attachments/20250210/dd30635b/attachment-0001.htm>