Patrick Gundlach
Im Fachbereich Informatik wird das X-Window System auf fast allen Unix Rechnern eingesetzt. Damit besteht die Möglichkeit, Programme auf entfernten Rechnern zu starten und auf eigenen Monitor die Ausgabe zu erhalten. Wie das gemacht wird und welche Probleme siche damit ergeben, soll hier kurz dargestellt werden.
Das X-Window System ist ein ,,netzwerk-transparentes`` Fenstersystem. Das heißt, daß es keinen Unterschied macht, ob ein Programm auf dem eigenen Rechner oder auf einem entfernten Rechner ausgeführt wird, wenn die Ausgabe auf dem Monitor erscheinen soll. In der X Terminologie gibt es Clients und Server. Dabei sind die Clients die auszuführenden Programme (zum Beispiel xclock) und der (X-)Server ist das Programm, das den Monitor und die Tastatur verwaltet. Damit nun nicht einfach ein Programm auf einem fremden Bildschirm dargestellt werden kann bzw. den Bildschirminhalt ausliest, muß man sich bei dem jeweiligen X-Server anmelden. Dieser entscheidet dann, ob der Client berechtigt ist, auf den Bildschirm zuzugreifen und ein Programm darstellen darf oder Informationen über den X-Server einholen kann. Das kann (hier) auf zwei verschiede Arten erfolgen.
Der xhost Mechanismus ist nicht zu empfehlen, da er sehr viele Sicherheitslücken hat: Alle Benutzer auf dem ,,geöffneten`` Rechner dürfen auf den X-Server zugreifen! Insbesondere auf Rechnern wie dem Studentenserver marvin, auf dem mehrere Benutzer gleichzeitig arbeiten, sollte der im nächsten Abschnitt beschriebene Mechanismus mit den Magic-Cookies benutzt werden.
Jeder X-Server verwaltet intern eine Liste derjenigen Rechner, deren Clients Zugangsberechtigung zum X-Server bekommen. Der Server läßt nur Verbindungen von Clients zu, deren Rechner in dieser Liste stehen. Jetzt kann man mit dem Programm xhost diese Liste verändern. Dazu muß man schon an dem Rechner angemeldet sein, auf dessen Bildschirm man zugreifen möchte, zum Beispiel mit einem xterm. Dann kann man durch aufrufen des Programms xhost sich diese Liste anzeigen lassen:
$ xhost access control enabled, only authorized clients can connectHier darf der lokale Rechner (grundsätzlich) auf den lokalen X-Server zugreifen. Jetzt könnte man einen Rechner namens ,,demosun`` durch den Befehl xhost +demosun zu dieser Liste hinzufügen. Das Ergebnis sieht dann so aus:
$ xhost access control enabled, only authorized clients can connect INET:demosunJetzt darf noch zusätzlich zum eigenen Rechner der Rechner mit dem Namen ,,demosun`` auf den X-Server zugreifen. Mit dem Befehl xhost + ohne Rechnernamen schaltet man die Kontrolle aus und erlaubt allen Rechner im Netz den Zugriff auf den Display Server:
$ xhost + access control disabled, clients can connect from any host $ xhost access control disabled, clients can connect from any host INET:demosunSomit kann jeder beliebige Rechner auf den Xserver zugreifen. Daher soll man ein xhost + tunlichst vermeiden.
Mit xhost - schaltet man nun die Kontrolle teilweise wieder ein. Die Liste der Rechner, die den Xserver kontaktieren dürfen, wird nicht gelöscht, daß heißt das diese Rechner immer noch auf den Bildschirm zugreifen können!
$ xhost - access control enabled, only authorized clients can connect $ xhost access control enabled, only authorized clients can connect INET:demosunAchtung: das Einschalten der Kontrolle gilt nur für zukünftige Verbindungen; die bestehenden Verbindungen werden nicht gekappt.
Seit X11 Release 4 gibt es einen Schutzmechanismus mit dem Namen
MIT-MAGIC-COOKIE-1. Der Mechanismus besteht aus einem Schlüssel in
Form einer 128 Bit langen Zahl, dem cookie. Dieser Schlüssel
wird bei jedem Einloggen neu generiert und dem X-Server bekannt
gemacht. Dieser Schlüssel wird in die Datei ~/.Xauthority
geschrieben. Wenn nun ein Client in Verbindung mit dem X-Server treten
möchte, dann muß er erst diesem Xserver den Schlüssel
mitteilen. Stimmt der Schlüssel nicht mit dem überein, der in der
Datei .Xauthority steht, dann weist der Xserver die Verbindung mit
folgender Fehlermeldung zurück:
$ xclock Xlib: connection to "sol:0.0" refused by server Xlib: Invalid MIT-MAGIC-COOKIE-1 key Error: Can't open display: sol:0.0
Wichtig ist, daß nur der Besitzer von .Xauthority Lese- und Schreibberechtigung für die Datei hat (chmod 600 .Xautority, sonst könnte jeder, sofern er Zugriff auf das Home Verzeichnis des Benutzers hat, diesen Schlüssel lesen und dann den X-Server kontaktieren).
Als erstes muß der Schlüssel übermittelt werden. Das ist aber nur nötig, wenn das Home Verzeichnis des entfernten Rechners nicht das gleiche ist, wie das des lokalen Rechners. (Die .Xauthority Dateien unterscheiden sich also.) Das geht am einfachsten durch ein kleines Shell Skript:
#!/bin/sh
/usr/openwin/bin/xauth extract - `uname -n`:0 | \
rsh $1 -l $2 /usr/openwin/bin/xauth merge -
Dieses Skript kopiert man sich am besten in seinen Pfad (zum Beispiel
unter den Namen xauth.sh) und ruft es
folgendermaßen auf:
$ xauth.sh rechnername benutzername
Jetzt ist der Schlüssel übertragen, und dem entfernten Rechner muß
man noch sagen, daß er das lokale Display benutzen soll (durch
Setzen der
DISPLAY Umgebungsvariablen auf dem entfernten Rechner):
export DISPLAY=rechnername:0.0 für die bash oder
setenv DISPLAY rechnername:0.0 für die (t)csh.
Wenn man auf mehreren Rechnern arbeitet kann man sich auch automatisch in der Start Datei das Display richtig setzen lassen:
Für die bash kann man in seiner ~/.bash_profile
folgende Zeile einfügen:
export DISPLAY=$(who am i | cut -c 38- | sed "s/(\(.*\))/\1/"):0.0Auf jeden Fall muß die korrekte Funktion ausprobiert werden. Insbesondere auf nicht-Solaris Rechnern muß das cut Kommando wahrscheinlich etwas angepaßt werden.
Wird nicht CDE unter Solaris 2.X benutzt, muß darauf achten, daß
Um den Schlüssel für den X-Server zu generieren, kann man folgendes Shell Skript benutzen:
!#/bin/sh
if ("`tty`" == /dev/console) then
set KUCHEN=`ps | cksum | bc | cut -c1-12`
xauth add :0.0 . ${KUCHEN}
xauth add `uname -n`:0.0 . ${KUCHEN}
endif
Unter Solaris kann dazu auch das Programm unter
/usr/openwin/lib/mkcookie/ benutzt werden. Aufgerufen wird das
Programm mit
$ /usr/openwin/lib/mkcookie Dateiname -auth magic-cookiemkcookie überschreibt aber eine schon vorhandene Datei. Das kann dazu führen, daß keine weiteren Programme mehr auf dem Bildschirm angezeigt werden können.
Diesen Schlüssel kann mit dem Kommando xauth list angezeigt
werden. Das ergibt eine Ausgabe wie:
localhost:0 MIT-MAGIC-COOKIE-1 63890aff48fa37f39584e60359afd9aa demosun:0 MIT-MAGIC-COOKIE-1 63890aff48fa37f39584e60359afd9aa demosun/unix:0 MIT-MAGIC-COOKIE-1 63890aff48fa37f39584e60359afd9aa
Um jetzt den X-Server mit dem Xauthority Mechanismus zu starten, ruft man unter Linux und SunOS den X-Server mit folgendem Befehl auf:
xinit ${HOME}/.xsession -- -auth ~/.Xauthority