After logging into a network via SSH, the network's default shell being used is BASH.
It is then possible to run applications which utilize graphics only if X11 forwarding has been enabled which I usually do via the -X option while logging in:

ssh -X user@network.to.connect.to

I notice that when it is enabled the DISPLAY environmental variable exists and is set as such DISPLAY=localhost:11.0, however there is nothing stopping the user from exporting an environmental variable named the same thing, making it look as if it has been enabled.

Is there a way from the bash shell or a bash script to determine if X11 Forwarding is enabled?

  • 1
    Possible duplicate of How to test that X11Forward is working or not? – user34720 Jan 4 '16 at 18:58
  • This is the client side configuration you are talking about , if X11 forwarding is not enabled on the server to which you connect , then you will not be able to establish such a connection. – Ijaz Ahmad Khan Jan 4 '16 at 19:08
  • It is enabled on the server, I just wish to know how to programmatically determine if it has been enabled for the connection. – John Jan 4 '16 at 19:09
  • Then you can issue a remote command to cat that file and grep the X11forwarding option , if it is yes then it is enabled – Ijaz Ahmad Khan Jan 4 '16 at 19:21
  • The referenced duplicate question assumes you can run 'ssh -v ...'; is this question specifically about testing the connection after running ssh? – Jeff Schaller Jan 4 '16 at 19:24

First, why? Why should a user fake DISPLAY? Nevertheless, I see two workarounds:

  1. readonly DISPLAY in bashrc/profile. If executed right at login, the user won't be able to set DISPLAY afterwards.
  2. xset q. Queries some X11 infos. Returns an error if no X11 session exists
  • I may be extra paranoid in thinking that a user would ever set their own DISPLAY variable, I am aware that this likely would never happen but when dealing with inexperienced Linux users I feel nothing is too far out of the question so IMO it's worth it to spend an extra few minutes and make sure things are less likely to break, that aside both methods seem to meet the requirement I was looking for. Particularly method 2 seems the most pragmatic for querying this info from within a shell script. – John Jan 4 '16 at 19:38
  • I actually shouldn't question other peoples paranoia, looking at the kind of paranoid code I write :). xset q should be included with most X11 setups. At least in Ubuntu it's a dependency of the xorg package. – Dominik R Jan 4 '16 at 19:48
  • I think it pays off to be a little paranoid sometimes, well at least with coding that is, but yes I found it on all the distributions I have access to at the moment so that seems a viable option. – John Jan 4 '16 at 20:12
  • @John In this case the paranoia does make sense, but for a different reason than what you think. If the user do set the DISPLAY variable, it is usually because they want to achieve some specific result, and you should honer the user's wish. But the DISPLAY variable will be inherited by child processes - some of which may live longer than the value in the DISPLAY variable remains valid. For example I could open an ssh connection with X11 forwarding, start screen, detach and disconnect. When I attach to the screen again using a new ssh connection it still has the old DISPLAY. – kasperd Jan 4 '16 at 22:38
  • readonly DISPLAY in bashrc/profile. If executed right at login, the user won't be able to set DISPLAY afterwards. Unless they really want to. See stackoverflow.com/questions/17397069/… A "readonly" variable in bash exists in the address space of a process owned by the very user you're trying to prevent from changing it. You really can't make that work. – Andrew Henle Jan 8 '16 at 10:43

Testing DISPLAY is the right thing. You can't do better, and any attempt to be smarter is very likely to hurt more than it helps.

Yes, of course, the user can lie and set DISPLAY to an incorrect value. But the user can also turn off their monitor; you never have a guarantee that they will see what you show. If the user has lied, you have no way to know anyway. It's possible for DISPLAY to be set to a value that causes the information to be displayed elsewhere (typically in another session of the same user). Conversely, it's possible for DISPLAY to be unset, or set to an invalid value, even though there would be a valid value, but you have no way to know what that value would be.

It's of course possible that DISPLAY will be set, but that you can't connect to the X server. In that case, the helpful thing to do is to print a clear error message. If DISPLAY is set but not usable, this indicates a misconfiguration somewhere, and you should convey this information to the user.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.