github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #239] Detect if being run on an SSH X-forwarded display and refuse to start if so #195

New issue

Open

opened 2026-05-05 05:39:11 -06:00 by gitea-mirror · 9 comments

gitea-mirror commented

2026-05-05 05:39:11 -06:00

Owner

Originally created by @brianjmurrell on GitHub (Jan 24, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/239

barrier[cs] should detect if it's being run on an X11 forwarded display and not start, or at least give the user a big warning, if it's found.

How could this be determined? Heuristically is one way. Is DISPLAY # >= 10? Is resolution of server and client the same? Are other SSH environment variables set?

Or one could look for a more unique property of an X display and see if they are == on both client and server. One could set an X property on the server and see if it's set on the client.

There are probably other ways.

Originally created by @brianjmurrell on GitHub (Jan 24, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/239 `barrier[cs]` should detect if it's being run on an X11 forwarded display and not start, or at least give the user a big warning, if it's found. How could this be determined? Heuristically is one way. Is DISPLAY # >= 10? Is resolution of server and client the same? Are other SSH environment variables set? Or one could look for a more unique property of an X display and see if they are == on both client and server. One could set an X property on the server and see if it's set on the client. There are probably other ways.

gitea-mirror added the

enhancement

label 2026-05-05 05:39:11 -06:00

gitea-mirror commented

2026-05-05 05:39:16 -06:00

Author

Owner

@jwestfall69 commented on GitHub (Jan 25, 2019):

I think just checking if the DISPLAY variable contains a non-empty hostname should be enough to tell you if its remote. Talking to the local X would have an empty hostname which causes clients to use to /tmp/.X11-unix/X0 unix domain socket.

@jwestfall69 commented on GitHub (Jan 25, 2019): I think just checking if the DISPLAY variable contains a non-empty hostname should be enough to tell you if its remote. Talking to the local X would have an empty hostname which causes clients to use to /tmp/.X11-unix/X0 unix domain socket.

gitea-mirror commented

2026-05-05 05:39:20 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Jan 25, 2019):

I don't think that is foolproof. localhost:0.0 is a perfectly valid DISPLAY value for a local X server.

But maybe the percentage of cases where that's used times the percentage of cases where somebody runs Barrier on such a remote display is so infinitesimally small that it's not worth worrying about.

@brianjmurrell commented on GitHub (Jan 25, 2019): I don't think that is foolproof. `localhost:0.0` is a perfectly valid `DISPLAY` value for a local X server. But maybe the percentage of cases where that's used times the percentage of cases where somebody runs Barrier on such a remote display is so infinitesimally small that it's not worth worrying about.

gitea-mirror commented

2026-05-05 05:39:23 -06:00

Author

Owner

@p12tic commented on GitHub (Jan 25, 2019):

I think it's important to correctly handle all cases. Having said that, the impact of a missed case won't be large if we give only a warning and not refuse to start outright.

@p12tic commented on GitHub (Jan 25, 2019): I think it's important to correctly handle all cases. Having said that, the impact of a missed case won't be large if we give only a warning and not refuse to start outright.

gitea-mirror commented

2026-05-05 05:39:26 -06:00

Author

Owner

@jwestfall69 commented on GitHub (Jan 25, 2019):

I don't think that is foolproof. localhost:0.0 is a perfectly valid DISPLAY value for a local X server.

Curious if you actually tried this? Putting the hostname will cause the client to attempt to connect to the X server via tcp instead of the unix domain socket. Most (all?) distros don't have their X listening on tcp.

[jwestfall@jwestfall:~]$ export DISPLAY=localhost:0.0
[jwestfall@jwestfall:~]$ xterm
xterm: Xt error: Can't open display: localhost:0.0

I also think the most that should be done is to log a warning.

@jwestfall69 commented on GitHub (Jan 25, 2019): > I don't think that is foolproof. `localhost:0.0` is a perfectly valid `DISPLAY` value for a local X server. Curious if you actually tried this? Putting the hostname will cause the client to attempt to connect to the X server via tcp instead of the unix domain socket. Most (all?) distros don't have their X listening on tcp. ``` [jwestfall@jwestfall:~]$ export DISPLAY=localhost:0.0 [jwestfall@jwestfall:~]$ xterm xterm: Xt error: Can't open display: localhost:0.0 ``` I also think the most that should be done is to log a warning.

gitea-mirror commented

2026-05-05 05:39:28 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Jan 25, 2019):

Yes, understood that most distros don't have X11 listening on TCP but that doesn't mean a user could not change that if they had a need. Before SSH and X11-forwarding (yes, I am that old), listening on TCP was the only way to get remote X11 clients on to your display.

There may be current-day use cases still that we are just not aware of.

But I agree that the odds are getting pretty low -- maybe too low to be worth supporting.

But it's still a good idea to recognise all of the use-cases and variables from the outset and then decide which valid and which are not.

@brianjmurrell commented on GitHub (Jan 25, 2019): Yes, understood that most distros don't have X11 listening on TCP but that doesn't mean a user could not change that if they had a need. Before SSH and X11-forwarding (yes, I am that old), listening on TCP was the only way to get remote X11 clients on to your display. There may be current-day use cases still that we are just not aware of. But I agree that the odds are getting pretty low -- maybe too low to be worth supporting. But it's still a good idea to recognise all of the use-cases and variables from the outset and then decide which valid and which are not.

gitea-mirror commented

2026-05-05 05:39:30 -06:00

Author

Owner

@ts-toh commented on GitHub (Jan 31, 2019):

I hope that there will be a way to override this feature if a user truly wants to. There are valid but intuitive use cases. For example, for awhile, I made a second monitor out of an old tablet running a vnc client over tcp/ip over usb to a new x11 instance on my desktop, and used synergy to control it. What if instead of using vnc, I wanted to tunnel an x11 session? It is frankly easier to do x11 over an ssh tunnel than a bare x11 session these days.

@ts-toh commented on GitHub (Jan 31, 2019): I hope that there will be a way to override this feature if a user truly wants to. There are valid but intuitive use cases. For example, for awhile, I made a second monitor out of an old tablet running a vnc client over tcp/ip over usb to a new x11 instance on my desktop, and used synergy to control it. What if instead of using vnc, I wanted to tunnel an x11 session? It is frankly easier to do x11 over an ssh tunnel than a bare x11 session these days.

gitea-mirror commented

2026-05-05 05:39:32 -06:00

Author

Owner

@p12tic commented on GitHub (Jan 31, 2019):

@brianjmurrell What was your original pain that resulted in opening this issue?

@p12tic commented on GitHub (Jan 31, 2019): @brianjmurrell What was your original pain that resulted in opening this issue?

gitea-mirror commented

2026-05-05 05:39:33 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Jan 31, 2019):

@p12tic sshing from the Barrier server machine to the client machine and then just running barrierc without first fixing DISPLAY to point at the remote machine's Xserver instead of the Barrier server's Xserver forwarded over the SSH connection.

@brianjmurrell commented on GitHub (Jan 31, 2019): @p12tic `ssh`ing from the Barrier server machine to the client machine and then just running `barrierc` without first fixing `DISPLAY` to point at the remote machine's Xserver instead of the Barrier server's Xserver forwarded over the SSH connection.

gitea-mirror commented

2026-05-05 05:39:34 -06:00

Author

Owner

@p12tic commented on GitHub (Jan 31, 2019):

Indeed a warning would be really useful in such case.

@p12tic commented on GitHub (Jan 31, 2019): Indeed a warning would be really useful in such case.

gitea-mirror referenced this issue

2026-05-05 06:42:58 -06:00

[GH-ISSUE #741] Enhancement: Allow mouse speed scaling for clients with dissimilar DPI #581