SDB:X-Client gibt die Fehlermeldung "Can't open display" aus

aus openSUSE, der freien Wissensdatenbank

Symptom

Unter dem SUSE Linux Enterprise Server 9 oder einer verwandten Version von SUSE Linux meldet ein X-Client, zum Beispiel xterm, während des Startvorgangs einen Fehler der Art Can't open display, zum Beispiel xterm Xt error: Can't open display: localhost:0.0.

Hintergrund

Das X Window System ist ein netzwerk-transparentes Window-System mit einer Client/Server-Architektur. X kann unterschiedliche Transportprotokolle benutzen, einschließlich Unix-Sockets (eine Inter-Prozess-Kommunikationsmöglichkeit, die lokal zum System ist) und TCP/IP-Sockets (Verbindungen benutzen das Internet-Protokoll). Welcher Mechanismus benutzt wird, hängt vom Inhalt der Umgebungsvariable DISPLAY ab. Wenn DISPLAY keinen Host-Namen enthält, z.B. wenn die Variable auf :0 gesetzt wurde, werden Unix-Sockets benutzt. Wenn die Variable einen Host-Namen enthält, z.B., wenn sie auf localhost:0.0 gesetzt wurde, versucht sich die X-Client-Anwendung anstatt über Unix-Sockets über TCP/IP-Sockets mit dem Server zu verbinden (im Beispiel mit localhost).

X verfügt über einen eigenen Authentifizierungsmechanismus, um zu entscheiden, welcher Client eine Verbindung zu einem Server aufbauen darf. Damit wird zum Beispiel verhindert, dass sich andere Benutzer Ihre X-Session anschauen oder diese manipulieren können.

Da das Internet zu einer zunehmend feindseligen Umgebung wurde, ist es gängige Praxis, nur dann Dienste zum Internet zu öffnen, wenn sie wirklich benötigt werden.

Mögliche Ursache #1: keine gültigen X-Authentifizierungs-Credentials

Unter dem Standard-X-Authentifizierungsmechanismus benötigt ein X-Client Zugriff auf ein gültiges X Session Cookie (dies ist im Wesentlichen ein gemeinsames Geheimnis zwischen dem X-Server und seinen Client-Anwendungen).

Wenn ein Benutzer mit dem Befehl su zu einem anderen Benutzer wechselt, werden die X-Session-Cookies nicht übernommen und folglich kann der Benutzer unter der ID zu der er gewechselt hat keine X-Anwendungen starten.

Lösung für das Problem der Authentifizierungs-Credentials: sux

Benutzen Sie sux anstelle von su, um die Benutzer-ID zu wechseln. Wie su wechselt auch sux zu einer neuen Benutzer-ID. Im Gegensatz zu su wird jedoch sichergestellt, dass die neu angenommene ID Zugriff auf das X-Session-Cookie erhält, so dass X-Anwendungen gestartet werden können.

Mögliche Ursache #2: der X-Server lauscht nicht

Es wird eine DISPLAY-Einstellung benutzt, die die X-Client-Anwendung veranlasst, zu versuchen TCP/IP-Sockets anstelle von Unix-Sockets zu verwenden. Dieser Versuch schlägt fehl, da in den letzten Releases von SUSE Linux aus Sicherheitsgründen der X-Server in der Standard-Einstellung n icht an TCP/IP-Sockets lauscht.

Lösung für lokale Verbindungen

Benutzen Sie in den Einstellungen für DISPLAY keinen Host-Namen, wenn, wie es meistens der Fall ist, der X-Server und der X-Client auf dem gleichen System laufen. In einer bourne-artigen Shell geben Sie hierzu DISPLAY=:0.0; export DISPLAY ein.

Bevorzugte Lösung für nicht-lokale X-Verbindungen: ssh

Wenn X-Server und X-Client auf unterschiedlichen Systemen laufen, gibt es zwei Möglichkeiten die Verbindung herzustellen.

Erstens, die Herstellung der Verbindung zum entfernten System mittels ssh -X. SSH (Secure Shell) ist der De-Facto-Standard für den entfernten Zugriff, der die Verbindung mittels kryptographischer Techniken gegen Abhören und Übernahme der Verbindung durch einen Angreifer (Session Hijacking) absichert. Mit der Option -X wird ssh angewiesen, für die Übertragung der X11-Verbindungen einen Tunnel einzurichten.

Alternative Lösung für nicht lokale X-Verbindungen: Aktivierung von TCP/IP-Socket-Verbindungen

Eine andere Lösung besteht darin, TCP/IP-Sockets für X11 wie folgt zu aktivieren:

• Setzen Sie in der Datei /etc/sysconfig/displaymanager DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN="yes"
• Rufen Sie /sbin/SuSEconfig auf, um diese Einstellung bekanntzumachen
• Starten Sie Ihren Display-Manager mittels /usr/sbin/rcxdm restart

Die Aktivierung von Netzwerkdiensten an einem Port erhöht die Anzahl der Möglichkeiten, die einem Eindringling für einen Angriff auf das System zur Verfügung stehen. Es gilt als gute Sicherheitspraxis, den Zugriff auf einen aktivierten Netzwerkdienst (wie X-Verbindungen über TCP-Port 6000) nur für autorisierte Systeme freizugeben. Dies kann mittels iptables-Regeln erreicht werden.

Da diese Lösung unhandlicher ist als die Benutzung von ssh -X, insbesondere unter dem Blickwinkel des Sicherheitsmanagements, sollte sie nur benutzt werden, wenn ssh -X nicht zur Verfügung steht (z.B. bei Problemen bezüglich der Zusammenarbeit mit älteren Systemene) .