3

While logged in remotely as ROOT, I want to run my selenium program remotely on ROOT's display (and not my remote display). I am not talking about doing ssh -X (which works), but instead I have one nodejs application spawning another nodejs application that uses selenium, all automatically without any user ssh'ing. But selenium needs to use a display of some sort in order to render some jpg files I need.

There are tons of questions that I've been looking at, but I am still struggling with the concept... The main sources of information that I've been using are:

Here's what I understand:

  • An X program needs two pieces of information in order to connect to an X display.
    • $DISPLAY
      • Typically :0 or :1 .
      • When I physically go to the laptop and view root's display (instead of remotely ssh'ing in), the $DISPLAY is set to :0 or :1.
    • $XAUTHORITY
      • The Magic Cookie to use is defined in ~/.Xauthority and the environment variable $XAUTHORITY.
      • When I physically go to the laptop (instead of remotely ssh'ing in), the $XAUTHORITY is set to /tmp/xauth-0-_0 (when $DISPLAY=:0) or /tmp/xauth-0-_1 (when $DISPLAY=:1).

=====================

Attempts

I've tried all these things:

  1. Setting $DISPLAY and $XAUTHORITY through a script

    • I have a script that spawns the nodejs selenium application. I exported these two variables in the script first before running the selenium application:

      if [ -e "/tmp/xauth-0-_0" ]
then
  export DISPLAY=":0"
  export XAUTHORITY="/tmp/xauth-0-_0"
elif [ -e "/tmp/xauth-0-_1" ]
then
  export DISPLAY=":1"
  export XAUTHORITY="/tmp/xauth-0-_1"
fi

#Then run the nodejs selenium app
node index.js

    • The error I get when I use this method is Invalid MIT-MAGIC-COOKIE-1 key[10332:10332:0713/112221.602744:ERROR:browser_main_loop.cc(272)] Gtk: cannot open display: :0.0

  2. Setting X11Forwarding yes in /etc/ssh/sshd_config, but I think this only applies to ssh -X

  3. Here are my other attempts at opening chrome:

    [root@localhost test]# xauth list
localhost:0  MIT-MAGIC-COOKIE-1  ....

[root@localhost test]# export XAUTHORITY=/tmp/xauth-0-_0

[root@localhost test]# export DISPLAY=localhost:0
[root@localhost test]# google-chrome
[10673:10673:0713/141603.418401:ERROR:browser_main_loop.cc(272)] Gtk: cannot open display: localhost:0

[root@localhost test]# export DISPLAY=127.0.0.1:0
[root@localhost test]# google-chrome
[10859:10859:0713/141617.346302:ERROR:browser_main_loop.cc(272)] Gtk: cannot open display: 127.0.0.1:0

I am using Fedora 23 (Server Edition) x86_64

Katie
  • 1,562
  • Did you log in under X as root? That's unusual. If you didn't, then root doesn't have a display. What do you mean by “ROOT's display”? – Gilles 'SO- stop being evil' Jul 14 '17 at 00:16
  • If your root user is currently logged in then it will work, if root is not logged in it can't work since there is no display. Have you tried just ssh'ing then typing DISPLAY=:0 and then trying to start a gui programm or did you just try your script + the weird localhost displays? – Ziazis Jul 14 '17 at 08:52
  • At attempt 3: DISPLAY=:localhost:0 would use a local tcp connection. Most X servers disable this for security reasons. Try unix socket connection with DISPLAY=:0 or DISPLAY=:unix:0 instead. Unix sockets of X reside in /tmp/.X11-unix/ – mviereck Jul 16 '17 at 15:41
  • Sorry, not DISPLAY=:unix:0 but DISPLAY=unix:0 – mviereck Jul 16 '17 at 15:55

2 Answers2

0

I've come to the conclusion that this isn't possible :(

You have to have a user ssh in sometime, somewhere in order for this to work.

Without a user, you can't take over root's display.

Katie
  • 1,562
0

If all you need is an X display for selenium, you can also start a second, independent X server using Xvfb ("virtual framebuffer X server"). This X server uses a chunk of memory as invisible framebuffer, and will allow selenium to pretend it is connected to an X server.

See man Xvfb for details, esp. the Examples section. You can start it without authorization enabled, so anyone can connect to it.

Note that this won't allow 3D acceleration (OpenGL), which is a completely different can of worms.

In general, attempting to take over another display, especially one where root is logged in, is a huge security risk: anyone connected to this display can capture key presses (and password), execute commands as root, etc. That's why normally you can't do it.

dirkt
  • 32,309