Session Manager behaviour with UDS listening sessions

[yghorbal]

Using macOS Viewer Version 3.1.1 (20240221) and RHEL 8.9 Server (Xvnc) 64-bit v3.1.1 (build 20240127) I started a session on the server with -uds option. The session is correctly created:

$ /opt/TurboVNC/bin/vncserver -uds -wm xfce

Desktop 'TurboVNC: youssef:1 (djo)' started on display youssef:1
Listening on Unix domain socket /home/djo/.vnc/youssef_1.uds

Starting applications specified in /opt/TurboVNC/bin/xstartup.turbovnc
Log file is /home/djo/.vnc/youssef:1.log

It's correctly listed on the server (with a weird WARNING though!)

$ /opt/TurboVNC/bin/vncserver -list

TurboVNC sessions:

X DISPLAY # PROCESS ID  NOVNC PROCESS ID

WARNING: youssef:1 is taken because abstract socket \0/tmp/.X11-unix/X1 is in use.
:1      14877

It's also correctly displayed in the Viewer when connected to the server's FQDN name:

But when I click "connect". I get this error message:

When starting the session without -uds, everything works as expected.

Does the Session Manager supposed to work with sessions listening on Unix Domain Sockets?

[dcommander]

It definitely does not work at the moment. I'll scope it out and see if it is something I can implement easily or whether it will require extensive modifications.

[yghorbal]

Thank you for the swift reply! I don't know if it's relevant, but the following works:

• having ssh key auth setup and working with server
• start an UDS session on server
• using "my_server_fqdn::/path/to/socket" in the Viewer

=> this shows the VNC auth window and access can proceed. If I understand correctly, in this case the session manager is not involved.

[dcommander]

Yes, you can use Unix domain sockets without the session manager. The session manager itself, however, still assumes that the session will be listening on a TCP port corresponding to its X display.

[dcommander]

In order to successfully generate an OTP for and connect to a TurboVNC session listening on a Unix domain socket, the TurboVNC Session Manager would need to know both the X display number of the session and the UDS on which it is listening. That would require extending the session manager protocol. Also, since Unix domain socket support requires an external SSH client, the session manager would need to be extended to handle external SSH clients. Otherwise, the built-in SSH client would be used for the session manager connection, and the external SSH client would be used for the RFB connection. I have added UDS support as a sub-feature of #148.

I did at least fix the warning.