Hallo Joachim,
From the keyboard of Joachim, Am 8 Jan 02, um 20:33, hatte Thomas Templin geschrieben:
oder was suchst Du?
Wenn ich von Rechner A auf Rechner B ein Fenster aufmachen will, dann muss ich dies auf Rechner B mit dem xhost-Befehl erlauben, dann auf A die DISPLAY-Variable setzen.
Mein Rechner B hat aber keinen xhost-Befehl. Laut Handbuch sollte der Zugriff für alle Rechner dieser Welt erlaubt sein, also standardmässig ein xhost +
Es könnte sein das der Zugriff erlaubt ist, es aber trotzdessen nicht geht.
Ist es aber nicht, da beim Start einer X-Anwendung auf A die Meldung der Xlib kommt, dass der Server (also B) den Zugriff verweigert. (Selbstverfreilich läuft auf allen Rechnern X und für lokale Anwendungen gibt es keine Probleme)
Irgendwo im System muss es eine Datei geben, in der für X vermerkt ist, welcher externe Rechner ein Fenster aufmachen darf.
Nein. man X: The list of allowed hosts is stored in the X server and can be changed with the xhost command.
Laut man xhost könnte das eine Datei X*.hosts sein. Eine solche Datei kann ich aber nirgends finden. Weder auf dem System B noch auf eine anderen Rechner C, der sonst alles genau richtig macht (SuSE 7.2). Die Datei auf C hat natürlich keine Auswirkungen auf B, könnte aber Hinweise liefern, wie es auf B zu machen wäre.
Meine Frage lautet also: Was macht xhost und wie kann ich es per Hand auf einem System, auf dem es kein xhost-Befehl gibt simulieren?
Gar nicht, AFAIK. Vielleicht schaust du dir mal den Schutzmechanismus MIT-MAGIC-COOKIE-1 genauer an. Im Homeverzeichnis deines Users wird die Datei .Xauthority mit dem Cookie angelegt. Dieser kann wohl auch kopiert werden, normalerweise wird wohl aber das Tool xauth verwendet.
Einfach via ftp das xhost-Binary kopieren macht keinen Sinn, da mein System B kein SuSE ist sondern irgendein vom Vertreiber selbstgebasteltes, stark rudimentäres Linuxsystem ist (Kernel?Libs?).
Ist denn der X-Server auf dem rudimentären System überhaupt mit bzw. ohne den richtigen Optionen gestartet? Per default wird X meist mit '-nolisten tcp' gestartet, da ein Starten ohne diesen Parameter den Zugriff auf eine Applikation (X-Server) erlaubt, die das suid-Bit gesetzt hat und somit effektive Rechte des Systemadministrators besitzt. Dies ist eine _potenzielle_ Sicherheitslücke, da X fehlerhaft sein könnte und somit ein Angreifer über das Netzwerk zu Administratorrechten gelangen könnte. Deswegen gibt es auch diverse Schutzmechanismen. man X Host Access Simple host-based access control. MIT-MAGIC-COOKIE-1 Shared plain-text "cookies". XDM-AUTHORIZATION-1 Secure DES based private-keys. SUN-DES-1 Based on Sun's secure rpc system. MIT-KERBEROS-5 Kerberos Version 5 user-to-user. Vielleicht ist da was dabei? man Xsecurity geht tiefer in die Materie ein. Um nochmal auf den Tipp von Thomas zu kommen, warum nicht ssh? Vorteil: - der komplette Kommunikationsweg ist verschlüsselt und komprimiert - das mergen von Xauthority-Daten erfolgt automatisch - das setzen von DISPLAY-Variablen entfällt Nachteil: - höhere Prozessorlast - langsamere Verwendung von X Clients, bei CPU-Schachen Maschinen Viel Erfolg bye Waldemar -- Are your questions smart enough? http://www.tuxedo.org/~esr/faqs/smart-questions.html