Can remote X11 clients connect to xpra X11 server in seamless mode?

[MayeulC]

I scoured the documentation and the Internet for an answer to this question, but couldn't find anything, so I imagine this use-case is not directly supported?

Desired setup

Host A

Xpra started in seamless mode:

xpra seamless :123

Host B

X11 app running here and displaying on host A

DISPLAY=A:123 xeyes

Explanation

This assumes that xpra (or Xvfb) listens for the X11 protocol on port 6123 when started by Xpra.
From what I've seen, this does not seem to be the case, and only a local unix socket is provided.

Rationale

Why would I want such a thing?
I am connecting to a HPC cluster. Xpra can run on one of the hosts, and multiple apps can run on different nodes. Usually this is not an issue with CLI & TUI programs, but there is the odd GUI app as well, that needs to be able to connect.

I understand that the "MIT-MAGIC-COOKIE" authentication scheme does not offer much security, and nothing is encrypted between hosts. But I am not a sysadmin on this system, and this is how it's currently used (with VNC instead of Xpra seamless), so introducing this would not significantly degrade security on this semi-trusted network.

Alternatives considered

Proxying

I guess I could technically proxy the local socket over the network? Possibly with socat. There may be some special considerations, but I do not think this is relevant when X11 apps initiate a TCP connection themselves.

Shadow / Desktop mode

Since these would connect to a working X11 server that already accepts client connections from the network, this should work; but it would not meaningfully improve the situation compared to VNC.
Especially as I have zero need for printing, audio, etc.

Replace X11 connections with something else?

I am open to suggestions, even from a theoretical standpoint, as I do not have admin access nor I am interested in pushing for a significant architectural change. Well, sometimes I do consider working elsewhere or in another field 😅

[totaam]

DISPLAY=A:123 xeyes

This is strongly discouraged, for two reasons:

• missing the correct environment, workaround in make it easier to run child commands with the correct environment #4676
• requires opening up the X11 server to TCP connections - insecure

To do that, remove the -nolisten tcp in your xvfb configuration:

xpra/fs/etc/xpra/conf.d/55_server_x11.conf.in

Line 40 in 751f2e3

# xvfb = Xvfb -nolisten tcp -noreset \

And deal with the security risks.

.. so introducing this would not significantly degrade security on this semi-trusted network.

I wouldn't, but OK.

Especially as I have zero need for printing, audio, etc.

These are much more secure and do not use TCP connections at all.

[MayeulC]

Thank you for the quick answer. After a lot of hair pulling (involving Ubuntu container versions, CA certs, xpra versions, etc), I ended up figuring that the correct option was -listen tcp (looks like Xvfb doesn't listen for tcp connections by default anymore, for good reasons).

I agree with the security risks, but this is how our IT rolls, I don't have much choice here. Theoretically the network is fully under their control, too. I don't really see alternatives for them either, short of running something like waypipe alongside every command.

These are much more secure and do not use TCP connections at all.

Right, but these are (I think?) the main differentiators xpra has against VNC in desktop/shadow mode; so the seamless mode is really the most appealing xpra feature to me (well, besides the generally better quality & performance).

Thanks also for the heads up about environment variables. Having a quick look at the list, they do not seem critical to my use-case, but I'll use that command when it lands in the packaged server, and set them manually when not directly starting something from xpra.

Usually environment variables are inherited when I start a job on another server (using IBM spectrum LSF), but right now I am running xpra in an apptainer container, so not inheriting the environment is kind of a point 😅

Leaving an annotated list of modified environment variables as documentation for myself and others, may be outdated by the time you read this.

Env var	Comment
UBUNTU_MENUPROXY=	will set it, but probably not useful as I do not use Ubuntu
XDG_CURRENT_DESKTOP=Xpra	Probably better to set, some apps may adapt their behavior to the currently set "i3"
XMODIFIERS=@im=none	Was previously unset, so I don't think that changes a lot
XPRA_LOG_DIR, XPRA_SERVER_LOG, XPRA_SERVER_SOCKET	probably not very important when not interacting with xpra commands, also the socket is local, so that may break across machines
QT4_IM_MODULE=xim, QT_ACCESSIBILITY=1, QT_IM_MODULE=xim	not personally using input methods or accessibility, but nice to have as a heads up
DISABLE_IMSETTINGS=1	ditto
IMSETTINGS_MODULE=none	ditto
GTK_IM_MODULE=xim	ditto
CLUTTER_IM_MODULE=xim	ditto
NO_AT_BRIDGE=1	Accessibility related as well, though good if it avoids errors
QT_QPA_PLATFORM=xcb	it was the only available anyway
GDK_BACKEND=x11	I suppose this is the same
GDK_SCALE=1	I would be surprised if it tried another scale, but let's avoid surprises
QT_X11_NO_NATIVE_MENUBAR=1	Probably a good idea to set
GTK_CSD=0	This as well
MWNOCAPTURE=true, MWNO_RIT=true, MWWM=allwm	Not using mono, but should probably set just in case
CKCON_X11_DISPLAY=:0	I had no idea that PAM could use another DISPLAY

[totaam]

Beware: many of these environment variables (in particular the input method ones, anything related to the DISPLAY) are set dynamically.
Also, some will be updated with newer xpra versions.

I suppose this is the same

No.

Not using mono

This has nothing to do with mono.

etc..