X-Win32 Knowledge Base   >   How to run X Clients as root from a StarNetSSH session

Search


About StarNet

StarNet Communications has been a leading developer of X Windows solutions since 1989. After establishing X-Win32 as the de facto standard in the higher education market during the early to mid-1990s -- 150 unlimited Campus Site Licenses worldwide -- X-Win32 has become of one the top three PC X servers in the government and commercial sectors as well.

Unlike its major rivals, Exceed (Hummingbird) and Reflection-X (WRQ/Attachmate), X-Win32 offers a highly focused PC X server that offers superior performance and productivity features, stability, ease of use and low cost (40% or better in most cases).

StarNet also delivers unequaled customer support. Our state-of-the-art engineering infrastructure allows us to fix problems and make a new release available quickly (overnight in many cases). As our testimonials page shows, StarNet customers consistently rate their X-Win32 experience as the best in the industry.




How to run X Clients as root from a StarNetSSH session

Starting an X Client as the root user from your X-Win32 SSH sessions with X11 Forwarding is, contrary to popular belief, actually quite simple. SSH sessions are a little different than rexec or rsh sessions because they use Xauthority data so that only authorized clients can tunnel X11 traffic over the SSH protocol connection. When you start X Clients as another user, other than the user that the session logged in as, you have to take care to ensure that both the XAUTHORITY and the DISPLAY environment variables get set correctly. We have prepared detailed instructions below to show how to do this. Note that the sudo approach is by far the easiest approach and is highly recomended.

Approaches to starting X Clients a root from SSH sessions

  1. “sudo xterm” – Use sudo to run an X program directly instead of ‘su’ing to root to run the x programs. Once you have root xterm up, you can then run other X programs with ease from that root xterm.
  2. “su” – with this approach the environment of the current user is inherited, so the DISPLAY environment variable remains set. The only problem here is that you have to set XAUTHORITY to point to the original users’s .Xauthority file, else the connection will be denied by the SSH X11 Forwarding mechanism. You can do this by running export XAUTHORITY=/home/user/.Xauthority or setenv XAUTHORITY /home/user/.Xauthority
  1. “su -” – with this approach the root user’s login scripts are processed and a new environment is created. You will have to echo $DISPLAY before running su -, then run export DISPLAY=localhost:10.0 (substituing the real display returned by echo) and export XAUTHORITY [...] as above.

    Output from the “sudo” approach


    user@survivor:~$ sudo xterm [ this xterm works ]
    user@host:~$

    Output from the “su” approach


    user@host:~$ sudo su
    root@host:/home/user# xterm
    X connection to localhost:10.0 broken (explicit kill or server shutdown).
    root@host:/home/user# echo $XAUTHORITY
    root@host:/home/user# export XAUTHORITY=/home/user/.Xauthority
    root@host:/home/user# echo $XAUTHORITY
    /home/user/.Xauthority
    root@host:/home/user# xterm [ this xterm works ]
    root@host:/home/user# exit
    exit

    Output from the “su -” approach


    user@host:~$ sudo su – root@host:~# xterm
    Warning: This program is an suid-root program or is being run by the root user.
    The full text of the error or warning message cannot be safely formatted
    in this environment. You may get a more descriptive message by running the
    program as a non-root user or by removing the suid bit on the executable.
    xterm Xt error: Can’t open display: %s
    xterm: DISPLAY is not set
    root@host:~# exit
    logout
    user@host:~$ echo $DISPLAY
    localhost:10.0
    user@host:~$ sudo su – root@host:~# export DISPLAY=localhost:10.0 ; export XAUTHORITY=/home/user/.
    Xauthority
    root@host:~# xterm [ this xterm works ]
    root@host:~#

    Category:Sessions -> SSH
    Category:FAQ