test

Solaris Handbuch für Fortgeschrittene Benutzer

Anhang D Netzwerkanwendungen

D.1 Netzwerkanwendungen

In diesem Anhang erfahren Sie, wie Sie mit Anwendungen arbeiten, die sich auf anderen Netzwerksystemen befinden.

Hinweis -

Die meisten Benutzer benötigen die hier enthaltenen Informationen nicht. Wenn Sie wissen möchten, ob auf entfernten Systemen spezielle Anwendungen zur Verfügung stehen, die für Sie interessant sein könnten, wenden Sie sich an Ihren System- oder Netzwerkverwalter.

Die im Arbeitsbereich von OpenWindows angezeigten Anwendungen laufen normalerweise alle auf Ihrem lokalen System ab. Wenn Ihre Workstation an ein Netzwerk angeschlossen ist, können Sie Anwendungen jedoch auch auf entfernten Systemen starten und auf dem lokalen Bildschirm anzeigen lassen. Auf diese Weise sparen Sie CPU-Kapazität und können unter Umständen auf Anwendungen zugreifen, die lokal nicht zur Verfügung stehen.

In den folgenden Abschnitten wird an einem einfachen Beispiel gezeigt, wie Sie eine Anwendung auf einem anderen System starten und auf Ihrem lokalen System anzeigen. Diese Anweisungen sollten jedoch nur als allgemeine Richtschnur verstanden werden, da der genaue Ablauf von der Konfiguration Ihrer Workstation und des Netzwerks abhängt. Im Abschnitt "D.3 Datensicherheit im Netzwerk" finden Sie weitere Hinweise, die beim Zugriff auf andere Netzwerksysteme beachtet werden müssen.

Damit Sie die nachfolgenden Schritte ausführen können, müssen folgende Bedingungen erfüllt sein:

Wenn Sie Fragen zu diesen Punkten haben, wenden Sie sich an Ihren Systemverwalter.

D.2 Zugriff auf entfernte Anwendungen (rlogin)

Bevor Sie auf die Anwendungen eines anderen Systems zugreifen können, müssen Sie die aktuellen Werte Ihrer Umgebungsvariablen prüfen:

Das folgende Beispiel zeigt, wie Sie mit rlogin eine Kommando-Shell auf einem entfernten System starten. Dabei wird davon ausgegangen, daß Ihr Home-Verzeichnis im Verzeichnis /home/meinverzeichnis auf dem entfernten System eingehängt und die OpenWindows-Software auf diesem System im Verzeichnis /usr/openwin installiert ist. Ersetzen Sie bei der Eingabe meinverzeichnis und meinsystem durch den entsprechenden Verzeichnis- bzw. Systemnamen und cmdtool durch den Namen der gewünschten Anwendung. 

$ rlogin entferntes_system

   .

   .

(Die folgenden Befehle werden auf dem entfernten System ausgeführt.)

   .

   .

$ HOME=/home/meinverzeichnis

$ DISPLAY=meinsystem:0

$ LD_LIBRARY_PATH=/usr/openwin/lib

$ /usr/openwin/bin/cmdtool &

Nach Eingabe der letzten Zeile erscheint auf Ihrem Bildschirm eine Kommando-Shell. Obwohl Sie mit dieser Anwendung genauso arbeiten wie mit lokalen Anwendungen, läuft sie tatsächlich auf dem entfernten System ab. In diesem Beispiel bringt Ihnen der Zugriff auf die entfernte Anwendung zwar keine großen Vorteile (die Kommando-Shell ist auf Ihrem System ebenfalls verfügbar und benötigt nicht sehr viel Rechenkapazität), aber Sie können auf diese Weise auch auf Anwendungen zugreifen, die auf Ihrem System nicht vorhanden sind oder nicht ablaufen können.

D.3 Datensicherheit im Netzwerk

Dieser Abschnitt enthält Informationen zur Datensicherheit im Netzwerk, die beim Zugriff auf entfernte Anwendungen beachtet werden sollten:

D.3.1 Voraussetzungen

Die Standard-Zugriffskontrolle von OpenWindows ab Version 3.3 muß nur dann geändert werden, wenn eine der folgenden Bedingungen erfüllt ist:

D.3.2 Zugriffskontrollverfahren

Das Zugriffskontrollverfahren legt fest, welche Clients oder Anwendungen auf den X11/NeWS-Server zugreifen dürfen. Ein Versuch, ohne entsprechende Berechtigung eine Verbindung zum Server herzustellen, wird mit folgender Fehlermeldung beendet. 

Xlib: connection to hostname refused by server

Xlib: Client is not authorized to connect to server

Der Verbindungsversuch wird auf der Serverkonsole protokolliert als:

AUDIT: <Datum Zeit Jahr>: X: client 6 rejected from IP 129.144.152.193

port 3485

	Auth name: MIT-MAGIC-COOKIE-1

Man unterscheidet zwischen benutzerorientierten und hostorientierten Kontrollverfahren. Benutzerspezifische Verfahren regeln den Zugriff auf die Zugangsberechtigungen (Accounts) der Netzwerkbenutzer, während hostspezifische Verfahren die Zugriffsrechte für ein bestimmtes System abfragen. Die benutzerspezifische Zugriffskontrolle kann beim Start von OpenWindows mit der Option -noauth abgeschaltet werden. Weitere Hinweise dazu finden Sie im Abschnitt "D.3.4 Zugriffskontrollverfahren ändern".

D.3.2.1 Benutzerorientierte Zugriffskontrolle

Bei einem benutzerorientierten Zugriffskontrollsystem können jedem Netzwerkbenutzer individuelle Zugriffsrechte zugewiesen werden. Greift ein Benutzer auf den Server zu, fragt dieser Autorisierungsdaten ab, die von der Client-Anwendung gesendet werden. Stimmen die Daten mit den auf dem Server gespeicherten Daten überein, erhält der Benutzer Zugang zu dem Server-System.

D.3.2.2 Hostorientierte Zugriffskontrolle

Bei einem hostorientierten Zugriffskontrollsystem werden Zugriffsrechte nicht an Benutzer, sondern an Hostsysteme vergeben. Da alle Benutzer eines berechtigten Systems auf den Server zugreifen können, bietet dieses Verfahren weniger Schutz vor unberechtigten Zugriffen als benutzerorientierte Verfahren.

Die Solaris-Systemumgebung unterstützt die hostorientierte Zugriffskontrolle, um Abwärtskompatibilität zu gewährleisten. Anwendungen, die mit Xlib- oder libcps-Bibliotheken verknüpft sind, die aus älteren OpenWindows- oder X11-Versionen stammen (älter als Version 2 bzw. Release 4), erkennen das neue benutzerorientierte Kontrollverfahren nicht. Damit auch diese Anwendungen auf den Server zugreifen können, muß der Benutzer entweder auf das hostorientierte Verfahren umschalten oder die Anwendungen mit aktuelleren Bibliotheksversionen verknüpfen.

Hinweis -

Aus Sicherheitsgründen sollte, soweit möglich, die zweite Methode verwendet werden.

D.3.3 Zugriffsprotokolle

OpenWindows Version 3.3 unterstützt die Zugriffsprotokolle MIT-MAGIC-COOKIE-1 und SUN-DES-1. Diese Protokolle arbeiten mit unterschiedlichen Autorisierungsdaten, die aber auf ähnliche Weise abgefragt werden. Auf einem Server kann immer nur ein Protokoll implementiert sein. OpenWindows arbeitet standardmäßig mit MIT-MAGIC-COOKIE-1, das ein benutzerorientiertes Kontrollverfahren verwendet.

D.3.3.1 MIT-MAGIC-COOKIE-1

Das Zugriffsprotokoll MIT-MAGIC-COOKIE-1 wurde am Massachussetts Institute of Technology entwickelt. Beim Start eines Systems über den Server wird für den Benutzer ein sogenanntes Magic Cookie erzeugt und auf dem Server gespeichert. Versucht dieser Benutzer danach, auf den Server zuzugreifen, sendet der Client das Magic Cookie zusammen mit der Verbindungsanforderung. Der Server vergleicht das Magic Cookie mit dem bei ihm gespeicherten Magic Cookie und stellt die Verbindung nur bei einer Übereinstimmung her.

D.3.3.2 SUN-DES-1

Das von Sun entwickelte Zugriffsprotokoll SUN-DES-1 basiert auf Secure RPC (Remote Procedure Call). Bei diesem Protokoll sendet der Client mit der Verbindungsanforderung den mit DES (Data Encryption Software) verschlüsselten Netzwerknamen des Benutzers. Der Server entschlüsselt den Namen und prüft, ob der Benutzer registriert ist.

SUN-DES-1 bietet einen höheren Zugriffsschutz als MIT-MAGIC-COOKIE-1, da der systemunabhängige Netzwerkname im Gegensatz zum Magic Cookie von anderen Benutzern nicht für den Serverzugriff verwendet werden kann.

Dieses Protokoll ist nur in Bibliotheken von OpenWindows Version 3 und nachfolgenden Umgebungen verfügbar. Anwendungen, die in Umgebungen vor OpenWindows Version 3 mit statischen Bibliotheken erzeugt wurden, darunter insbesondere Xlib, können dieses Zugriffsprotokoll nicht einsetzen.

Wenn Sie anderen Benutzern Zugang zu Ihrem Server verschaffen wollen, können Sie ihre Netzwerknamen in die Zugriffsliste des Servers aufnehmen. Einzelheiten dazu finden Sie im Abschnitt "D.3.4.3 Zugriffsberechtigungen vergeben (SUN-DES-1)".

D.3.3.3 Standardprotokoll ändern

Beim Start von OpenWindows können Sie über Befehlsoptionen angeben, daß statt MIT-MAGIC-COOKIE-1 das Protokoll SUN_DES-1 verwendet oder überhaupt keine benutzerorientierte Zugriffskontrolle stattfinden soll. Um auf SUN-DES-1 umzuschalten, starten Sie OpenWindows mit folgendem Befehl: 

example% openwin -auth sun-des

Wenn kein benutzerorientiertes Kontrollverfahren verwendet werden soll, geben Sie in der Befehlszeile die Option -noauth an: 

example% openwin -noauth

Achtung - Achtung -

GraphicMit der Option -noauth wird der Zugriffsschutz erheblich reduziert. Da nach der Deaktivierung der benutzerorientierten Zugriffskontrolle nur noch die Berechtigung des zugreifenden Systems abgefragt wird, kann jeder Benutzer, der Zugriff auf Ihr System hat, auch auf den Server zugreifen.

D.3.4 Zugriffskontrollverfahren ändern

Wenn Sie die benutzerorientierte Zugriffskontrolle nicht mit der Option -noauth deaktiviert haben (siehe "D.3.3.3 Standardprotokoll ändern"), sind beide Kontrollverfahren aktiv. Der Server fragt zunächst die Berechtigung des Benutzers und dann die des Systems ab. Bei der Abfrage der Benutzerdaten wird standardmäßig MIT-MAGIC-COOKIE-1 verwendet, während die Systemdaten gegen eine leere Liste geprüft werden, d. h. tatsächlich wirksam ist nur die benutzerorientierte Zugriffskontrolle. Mit der Option -noauth weisen Sie den Server an, dieses Kontrollverfahren abzuschalten und die hostorientierte Zugriffskontrolle durch Aufnahme des lokalen Systems in die Hostliste zu initialisieren.

Das vom Server verwendete Zugriffskontrollverfahren kann über eines der Programme xhost und xauth geändert werden. Weitere Informationen hierzu finden Sie in den man pages. Diese Programme greifen auf zwei Binärdateien zu, die von dem Zugriffsprotokoll erzeugt werden und verbindungsspezifische Autorisierungsdaten enthalten. Die eine Datei wird nur vom Server verwendet, die andere befindet sich im Home-Verzeichnis des Benutzers:

Mit dem Programm xhost bearbeiten Sie die Hostliste auf dem Server. Sobald Sie einen Hostnamen in die Liste aufnehmen, wird der Zugriffsschutz reduziert, da nun alle Benutzer dieses Systems auf den Server zugreifen können, ohne sich weiter ausweisen zu müssen (siehe "D.3.2.2 Hostorientierte Zugriffskontrolle").

Mit dem Programm xauth greifen Sie auf die Autorisierungsdaten in der Client-Datei .Xauthority zu. Sie können diese Daten beispielsweise einem anderen Benutzer zur Verfügung stellen, der sie dann in seine Client-Datei einträgt, und ihm so den Zugriff auf Ihren Server ermöglichen.

Weitere Hinweise zur Verwendung von xhost und xauth finden Sie im Abschnitt "D.3.4.2 Zugriffsberechtigungen vergeben (MIT-MAGIC-COOKIE-1)".

D.3.4.1 Die Datei .Xauthority

Die Datei .Xauthority enthält Einträge in folgendem Format: 

Verbindungsprotokoll         Zugriffsprotokoll       

Autorisierungsdaten

Normalerweise ist als Zugriffsprotokoll nur MIT-MAGIC-COOKIE-1 angegeben, und die erste und dritte Spalte enthalten nur Einträge für das lokale System. Auf dem Host anyhost könnte der Inhalt der Datei .Xauthority beispielsweise so aussehen: 

anyhost:0      MIT-MAGIC-COOKIE-1  82744f2c4850b03fce7ae47176e75

localhost:0    MIT-MAGIC-COOKIE-1

 82744f2c4850b03fce7ae47176e75

anyhost/unix:0 MIT-MAGIC-COOKIE-1 82744f2c4850b03fce7ae47176e75

Beim Start des Clients wird der entsprechende Eintrag aus der Datei .Xauthority gelesen, und die Daten aus den Spalten 2 und 3 werden zusammen mit der Verbindungsanforderung an den Server gesendet. In der Standardkonfiguration liefern xhost und newshost leere Host-Zugriffslisten zurück und melden, daß die Zugriffskontrolle aktiviert wurde.

Wenn Sie statt des Standardprotokolls das Protokoll SUN-DES-1 gewählt haben, ist in der Datei .Xauthority in Spalte 2 SUN-DES-1 und in Spalte 3 der Netzwerkname des Benutzers angegeben. Der Netzwerkname erscheint in folgendem Format: 

unix.benutzer_id@NISdomain_name

Auf dem Host anyhost könnte der Inhalt der Datei .Xauthority beispielsweise so aussehen (unix.15339@EBB.Eng.Sun.COM ist der systemunabhängige Netzwerkname des Benutzers):

anyhost:0        SUN-DES-1            "unix.15339@EBB.Eng.Sun.COM"

localhost:0      SUN-DES-1            "unix.15339@EBB.Eng.Sun.COM"

anyhost/unix:0   SUN-DES-1            "unix.15339@EBB.Eng.Sun.COM"

Hinweis -

Wenn Sie Ihren Netzwerknamen nicht kennen, wenden Sie sich bitte an Ihren Systemverwalter.

D.3.4.2 Zugriffsberechtigungen vergeben (MIT-MAGIC-COOKIE-1)

Wenn Sie das Zugriffsprotokoll MIT-MAGIC-COOKIE-1 verwenden, können Sie einen Benutzer folgendermaßen für den Zugriff auf Ihren Server berechtigen:

  1. Extrahieren Sie auf dem Server mit xauth einen Eintrag im Format hostname:0 in eine Datei.

    In diesem Beispiel wird als Hostname anyhost und als Dateiname xauth.info: verwendet:

    myhost% /usr/openwin/bin/xauth nextract

- anyhost:0 > $HOME/xauth.info

  2. Senden Sie die Datei (z. B. mit der Anwendung Post" oder dem Programm rcp) an den Benutzer, der zugriffsberechtigt werden soll.

    Hinweis -

    Aus Datenschutzgründen sollten Sie die Datei möglichst per elektronische Post versenden. Wenn Sie rcp verwenden, sollten Sie die Datei nicht in einem Verzeichnis ablegen, auf das von anderen Benutzern leicht zugegriffen werden kann.

  3. Der Empfänger der Datei muß den Eintrag in die Datei .Xauthority in seinem Home-Verzeichnis aufnehmen.

    Zum Beispiel:

    userhost% /usr/openwin/bin/xauth nmerge - < xauth.info

    Hinweis -

    Da die Autorisierungsdaten verbindungsspezifisch sind, werden sie bei einem Neustart des Servers ungültig.

D.3.4.3 Zugriffsberechtigungen vergeben (SUN-DES-1)

Wenn Sie das Zugriffsprotokoll SUN-DES-1 verwenden, können Sie einen Benutzer folgendermaßen für den Zugriff auf Ihren Server berechtigen:

  1. Registrieren Sie den Benutzer mit xhost auf dem Server.

    In diesem Beispiel wird Benutzer somebody für das System myhost: zugriffsberechtigt:

    myhost% xhost + somebody@

  2. Der neue Benutzer muß den Eintrag mit xauth in die Datei .Xauthority in seinem Home-Verzeichnis übernehmen.

    In diesem Beispiel lautet der Netzwerkname des neuen Benutzers unix.15339@EBB.Eng.Sun.COM. Bei der Eingabe muß auf das Pipe-Zeichen ein Leerzeichen folgen. 

    userhost% echo 'add myhost:0 SUN-DES-1 "unix.15339@EBB.Eng.Sun.COM"' | $OPENWINHOME/bin/xauth

D.3.5 Clients auf entfernten Systemen oder lokal unter anderem Benutzernamen starten

X-Clients rufen den Namen des Servers, zu dem die Verbindung hergestellt werden soll, aus der Umgebungsvariablen DISPLAY ab.

So starten Sie eine Client-Anwendung auf einem entfernten oder unter einem anderen Namen auf dem lokalen System:

  1. Berechtigen Sie einen anderen Benutzer zum Zugriff auf den Server.

    Folgen Sie dazu den Anweisungen im Abschnitt "D.3.4.2 Zugriffsberechtigungen vergeben (MIT-MAGIC-COOKIE-1)" oder "D.3.4.3 Zugriffsberechtigungen vergeben (SUN-DES-1)".

  2. Setzen Sie DISPLAY auf den Namen des Hosts, auf dem der Server läuft.

    In diesem Beispiel heißt der Host remotehost:

    myhost% setenv DISPLAY remotehost:0

  3. Starten Sie das Client-Programm. 

    myhost% client_program&

    Der Client wird auf dem entfernten System (remotehost) angezeigt.