If you did not migrate your account yet, visit https://idp-portal-info.suse.com/
SDB:X Client Produces "Can't open display" Error
- 1 Symptom
- 2 Background
- 3 Possible cause #1: no valid X authentication credentials
- 4 Solution to the authentication credentials problem: sux
- 5 Possible cause #2: the X server isn't listening
- 6 Solution for local connections
- 7 Preferred solution for non-local X connections: ssh
- 8 Alternative solution for non-local X connections: enable TCP/IP socket connections
- 9 More information on running X applications remotely
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.
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>