SDB:X Client Produces "Can't open display" Error

Symptom

Under SUSE Linux Enterprise Server 9 or a related version of SUSE Linux, an X client application, for example xterm, reports an error Can't open display on startup, for instance xterm Xt error: Can't open display: localhost:0.0.

Background

The X Window System is a network transparent window system that uses a client/server-architecture. X can use a number of transport protocols, including Unix sockets (which are an inter-process communication facility that is local to a system) and TCP/IP sockets (connections using the Internet protocol s uite). Which mechanism is used, is determined by the format of the DISPLAY environment variable. When DISPLAY does not contain a hostname, e.g. it is set to :0, Unix sockets will be used. When it does contain a hostname, e.g. it is set to localhost:0.0, the X client application will try to connect to the server (in the example, localhost) via TCP/IP sockets rather than via Unix sockets.

X has its own authentication mechanism to determine whether a client is allowed to connect to a server; this is used, for example, to prevent another user from being able to view or manipulate your X session.

As the Internet has become an increasingly hostile environment, it has become good practice to only open up services to the Internet when they are really needed.

Possible cause #1: no valid X authentication credentials

With the default X authentication mechanism, an X client needs to have access to a valid X session cookie (which is, essentially, a shared secret between the X server and its clients).

When a user switches to a different user using the su command, X session cookies are not transferred and thus the user cannot start X applications under the user id to which he or she switched.

Solution to the authentication credentials problem: sux

Instead of su, use sux to switch user id. Like su, sux switches to a different user id. Unlike su, it ensures that the id being assumed is given access to the X session cookie so that X applications can be started.

Possible cause #2: the X server isn't listening

A DISPLAY setting is used which causes the X client application to attempt to use TCP/IP sockets rather than Unix sockets. This attempt fails because in recent releases of SUSE Linux the X server does not listen to TCP/IP sockets by default, for security reasons.

Solution for local connections

When, as is mostly the case, the X server and the X client application are running on the same system, do not use a hostname in the DISPLAY settings. In a bourne style shell, do DISPLAY=:0.0; export DISPLAY.

Preferred solution for non-local X connections: ssh

When the X server and the X client application are to run on different systems, there are two ways to enable the connection.

The first is to connect to the remote system using ssh -X. SSH (secure shell) is a de facto standard remote access mechanism that uses cryptographic techniques to secure connections against wiretapping and session hijacking. The -X option to ssh tells it to try to set up a tunnel through which X11 connections can be forwarded.

Alternative solution for non-local X connections: enable TCP/IP socket connections

Another solution is to enable TCP/IP sockets for X11 as follows:

• Set DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN="yes" in the /etc/sysconfig/displaymanager file
• Running /sbin/SuSEconfig to propagate that setting
• Restart your display manager through /usr/sbin/rcxdm restart

Enabling a network service on a port increases the ways a system may be attacked by a cracker. As a good security practice, when a network service (like X connections via TCP port 6000) is enabled, access to it should be restricted to authorised systems only, e.g. via iptables rules.

As this solution is more cumbersome than using ssh -X, in particular from a security management point of view, it should only be used when ssh -X isn't an option (e.g. due to interoperability issues with legacy systems).

More information on running X applications remotely

The Remote X Apps mini-HOWTO contains more information on how to run X applications remotely in a secure fashion, including the use of xauth to implement access control based on a shared secret (a so called magic cookie) rather than the insecure hostname or username based access control using xhost. <keyword>X11,DISPLAY,sux,xauth,xhost,magic,cookie,ssh,displaymanager</keyword>