Rendered at 14:20:41 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
yjftsjthsd-h 17 hours ago [-]
> You'll often see xhost + suggested as the "just make it work" answer, and it does — by turning host-based access control off entirely. Every client from every host can then connect to your display without any cookie at all.
> On a single-user machine that sounds harmless, but X has no isolation between clients: anyone who can reach the server can read your keystrokes, grab the contents of any window, and inject synthetic input. xhost + hands that capability to every local user and, if your server listens on TCP, to the network. Even the narrower xhost +local: still trusts every UID on the box.
Does modern Xorg even support TCP? I know it doesn't default to allowing it, and the last time I actually wanted to run X11 over the network I ended up using socat against the socket file. Controlling access by user could have some value, but only under very specific threat models, especially since containers won't be able to reach the socket unless you give it to them on purpose. (Actually, can you just chmod o-rwx the socket?)
So I'm really skeptical of ever practically needing a more complicated fix when you can just xhost +
jolmg 15 hours ago [-]
> Does modern Xorg even support TCP?
Yes. It works well. X11 over Wireguard works so much better than ssh -X. Haven't tried over the internet, but in a LAN you can't tell the difference between local and remote windows, at least with Emacs.
guenthert 2 hours ago [-]
> Haven't tried over the internet,
It works, the user experience however might not be great. Latency is your enemy, as are occasional drop-outs. For remote connections outside a LAN, naked X11 isn't recommended. NoMachine's NX (or the shrink wrapped X2Go) were better suited for such.
jolmg 28 minutes ago [-]
Bit puzzling how one looks at guides for NoMachine's NX / FreeNX / X2Go and they're all about desktop sharing instead of simply remote X11 clients though X11 compression which is what NX was about. It seems the tunneling through NX's X11 compression is done through the bit obscure nxproxy.
guenthert 6 minutes ago [-]
The proxy is needed for session management (specifically suspending sessions), no?
inigyou 2 hours ago [-]
Yes it supports TCP. It needs some obscure option to enable it.
10 minutes ago [-]
ButlerianJihad 16 hours ago [-]
It is likely that your desktop Linux distro, or whatever, is configured out-of-box to run the X server that only listens on the unix:0 domain.
You can reconfigure it, restart it, or start a secondary server. And check your firewall/packet filtering setup while you're at it.
There are several cryptographic security methods for the xauth(1) system.
Notably, "si" or "server interpreted" is not cryptographically secure. However, you can share MIT-MAGIC-COOKIE values easily by copy-paste into another user's xauth command.
bobmcnamara 15 hours ago [-]
X11TCP is blazing fast compared to X11SSH
maxwell_smart 15 hours ago [-]
SSH can't send out a packet for every keystroke as soon as it gets it-- otherwise it's susceptible to timing attacks based on minute variations in speed of hitting different combinations of letters on the keyboard.
wahern 14 hours ago [-]
If I understand the code correctly, OpenSSH only injects delays and chaff when you're actively typing data through an interactive session directly to the ssh client itself (i.e. it's reading your key strokes from the TTY, as opposed to keystrokes being sent as opaque data over the X11 channel). There would be no disruption to X11 forwarding while you're not actively typing, and even then there's no delay if it can bundle key presses with non-interactive data. See https://github.com/openssh/openssh-portable/blob/088ca00/cli...
For a full desktop session, X11 over TCP should be much faster just because each X11 client app has it's own TCP connection, whereas for SSH X11 forwarding every app is tunneled over a single TCP connection.
jolmg 13 hours ago [-]
> For a full desktop session, X11 over TCP should be much faster just because each X11 client app has it's own TCP connection, whereas for SSH X11 forwarding every app is tunneled over a single TCP connection.
But even with a single X11 connection, the difference in performance is huge between it being tunneled through SSH and not.
Also, whether you have one connection or multiple between 2 hosts, it's still the same bandwidth for the most part.
somat 11 hours ago [-]
Running X open as a sort of shared network attached monitor is pretty fun, granted it is only really useful as a sort of large control room style display as all window operation have to run via cli tools.
But it is neat for anyone to just be able to throw a application up on the big master display.
TacticalCoder 17 hours ago [-]
> xhost + hands that capability to every local user and, if your server listens on TCP, to the network. Even the narrower xhost +local: still trusts every UID on the box.
I'm not defending xhost or advocating to use it but... If you mention narrower version of xhost, then why stop at:
xhost +local:
and not mention that you can do:
xhost +si:localuser:jack
As an intriguing unrelated sidenote you can do:
xhost +si:localuser:jack
open an app, then do:
xhost -si:localuser:jack
and then user jack cannot, except through the app already launched, display on the X server.
lysace 16 hours ago [-]
Memories from '96: We had these beefy/expensive Sun computers at the university we called "cpu servers". At home we ran Linux with XFree86 (or sometimes Windows 95/NT with Exceed) on like a 486. In between a 10 Mbit/s Ethernet network. Everything had public IPs. Cleartext telnet was still the norm.
We ran some weird X11-based apps on these Sun machines required for courses that way. Web browsing was faster locally, even with a lowly 486.
> On a single-user machine that sounds harmless, but X has no isolation between clients: anyone who can reach the server can read your keystrokes, grab the contents of any window, and inject synthetic input. xhost + hands that capability to every local user and, if your server listens on TCP, to the network. Even the narrower xhost +local: still trusts every UID on the box.
Does modern Xorg even support TCP? I know it doesn't default to allowing it, and the last time I actually wanted to run X11 over the network I ended up using socat against the socket file. Controlling access by user could have some value, but only under very specific threat models, especially since containers won't be able to reach the socket unless you give it to them on purpose. (Actually, can you just chmod o-rwx the socket?)
So I'm really skeptical of ever practically needing a more complicated fix when you can just xhost +
Yes. It works well. X11 over Wireguard works so much better than ssh -X. Haven't tried over the internet, but in a LAN you can't tell the difference between local and remote windows, at least with Emacs.
It works, the user experience however might not be great. Latency is your enemy, as are occasional drop-outs. For remote connections outside a LAN, naked X11 isn't recommended. NoMachine's NX (or the shrink wrapped X2Go) were better suited for such.
You can reconfigure it, restart it, or start a secondary server. And check your firewall/packet filtering setup while you're at it.
There are several cryptographic security methods for the xauth(1) system.
https://manpages.ubuntu.com/manpages/resolute/man7/Xsecurity...
Notably, "si" or "server interpreted" is not cryptographically secure. However, you can share MIT-MAGIC-COOKIE values easily by copy-paste into another user's xauth command.
For a full desktop session, X11 over TCP should be much faster just because each X11 client app has it's own TCP connection, whereas for SSH X11 forwarding every app is tunneled over a single TCP connection.
But even with a single X11 connection, the difference in performance is huge between it being tunneled through SSH and not.
Also, whether you have one connection or multiple between 2 hosts, it's still the same bandwidth for the most part.
But it is neat for anyone to just be able to throw a application up on the big master display.
I'm not defending xhost or advocating to use it but... If you mention narrower version of xhost, then why stop at:
and not mention that you can do: As an intriguing unrelated sidenote you can do: open an app, then do: and then user jack cannot, except through the app already launched, display on the X server.We ran some weird X11-based apps on these Sun machines required for courses that way. Web browsing was faster locally, even with a lowly 486.