5

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 [email protected]

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?

Improve this question
5
  • 1
    Possible duplicate of How to test that X11Forward is working or not?
    – user34720
    Jan 4, 2016 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
    Jan 4, 2016 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, 2016 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
    Jan 4, 2016 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, 2016 at 19:24

3 Answers 3

Reset to default
6

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
Improve this answer
5
  • 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, 2016 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, 2016 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, 2016 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, 2016 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, 2016 at 10:43
4

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.

Improve this answer
0

From what I understand, you can't tell from testing the DISPLAY variable, however, when establishing an SSH session, there is an SSH_CONNECTION environment variable. X11-Forarding does not use xhost, but if the SSH_CONNECTION variable exits and you can use xhost without producing an error, then you obviously have a X capable connection, hence X11-Forwarding.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .