Remote X Apps mini-HOWTO

v, 19 November 1999

Deze mini-HOWTO beschrijft hoe je remote X applicaties kan draaien. Dit betekend dat je een X programma van de ene computer op een andere computer kunt draaien. Simpel gezegd: hoe kan ik een X programma draaien op een andere computer dan de computer waar ik achter zit. Het kenmerk van deze mini-HOWTO is veiligheid. Deze mini-HOWTO bevat ook informatie over het runnen van X applicaties lokaal met verschillende ussers.

IntroductieDeze mini-HOWTO is een handleiding over hoe te doen met remote X applicaties. Hij is geschreven om verschillende redenen. Er zij al veel vragen gesteld over het draaien van remote X applicaties in de newsgroepen. Ik zie heel veel hints als ``gebruik xhost + hostname''of zelfs ``xhost +'' om X connecties toe te staan. Dit is belachelijk onveilig, want er zijn betere methodes. Ik ken geen eenvoudig document dat de opties beschrijft die je hebt. Mail mij als jij iets beters weet.Dit document is geschreven met unix achtige systemen in mijn gedachten. Maar ook al is je lokaal of remote besturings systeem van een ander merk, dan kun je hier toch vinden hoe sommige dingen werken, je zal wel enige dingen moeten aanpassen voor gebruik met je eigen systeem(en). De meest recente versie van dit document is altijd aanwezig op WWW . Het is ook altijd aanwezig op de Remote X Apps mini-HOWTO op . Linux (mini-)HOWTOs zijn aanwezig op http of ftp van .Dit is versie 0.6.1. Geen waarborg, enkel goede bedoelingen. Ik ben open voor suggesties, ideeën, nuttige toevoegingen, (fout) correcties, Etc .. Ik wil dat dit een simpel document blijft, alhoewel met de beste bedoeling In HOWTO stijl. De laatste update dateert van 19 November 1999 door Aanverwante documentatieEen vergelijkbaar document op WWW is ``What to do when Tk says that your display is insecure'', . Dit is geschreven door . het is een vergelijkbare oplossing voor X authentificatie zoals (xauth) in dit document. Alhoewel Kevin zich meer spitst op het gebruik van xdm met xauth. Het X Windows systeem Vol 8 X ``Window System Administrator's Guide'' van is ook een goede bron van informatie. Enkel ben ik niet in staat geweest om dit te checken.Een ander document dat veel lijkt op dat wat je nu leest met als titel ``Securing X Windows'' is aanwezig op .Kijk ook eens in de newsgroepen, zoals comp.windows.x, comp.os.linux.x, en comp.os.linux.networking.Een voorbeeldJe gebruikt twee computers, en je gebruikt het X windows systeem van de eerste om te typen en om naar te kijken. Je gebruikt de tweede om wat belangrijk grafisch werk op te doen. Je wilt de tweede gebruiken om naar de uitvoer op het scherm te kijken van de eerste. Dit maakt het X windows systeem mogelijk.Je hebt hier natuurlijk een netwerk-connectie voor nodig. Het liefst een snelle; Het X protocol is een netwerk slak. Maar met een beetje geduld en een geschikt compressie protocol, kun je zelfs X applicaties runnen via een modem. Voor het X compressie protocol moet je even kijken op dxpc of LBX (ook bekent als ).Je moet twee dingen doen om dit te volbrengen: Vertel het lokale display (server) dat hij connecties moet accepteren van een remote computer Vertel de remote applicatie (client) dat hij zijn output naar het lokale display moet sturen Een beetje theorieHet magische woord is DISPLAY. In het X window systeem bestaat het display (simpel gezegd) uit een keyboard, muis en een scherm. Een display wordt aangestuurd door een server programma beter bekend als de X server. De server bediend de display mogelijkheden van programma's die ermee connecten.Een display wordt aangegeven met een naam bv: DISPLAY=light.uni.verse:0 DISPLAY=localhost:4 DISPLAY=:0 Een display bestaat uit een host naam ( zoals light.uni.verse en localhost), een dubbele punt (:), een volgorde nummer (zoals 0 en 4). De host-naam van de display is de naam van de computer waar de X server draait. Als je de host-naam weg laat betekent dit de lokale host. Het volgorde nummer is normaal 0 - maar het kan varieer-en als er meerdere Displays zijn aangesloten op een computer.Als je ooit een display tegenkomt met een extra .n indicatie erachter, dan is dat het scherm nummer. Een display kan eigenlijk meer schermen aan. Een display kan eigenlijk meerdere schermen aan. Normaal is er maar een scherm, met het nummer n=0, dus dat is standaard.Andere formaten van DISPLAY zijn er, maar die hierboven doet het goed voor onze plannen.Voor technische nieuwsgierigheid: hostname:D.S Betekend S op display D van host hostname; de X server voor dit display luistert op de TCP poort 6000+D. host/unix:D.S betekend scherm S op display D van host host; de X server voor dit display luistert op de UNIX domein socket /tmp/.X11-unix/XD listening (dus hij is alleen berijkbaar vanaf host) :D.S is hetzelfde als host/unix:D.S, waar host de locale hostname is. De client vertellenHet client programma (Bijvoorbeeld je grafische applicatie) weet naar welk display hij moet connecten door te kijken naar het DISPLAY variabel. Deze instelling kan veranderd worden, door de client als optie -display hostname:0 te geven als je hem opstart. Sommige van deze voorbeelden zullen dit duidelijker maken.Onze computer, is bekend voor de andere computers als light, en we zitten in het domein uni.verse. Als we een normale X server draaien, de display is bekend als light.uni.verse:0. We willen het tekenprogramma xfig runnen op een remote computer, die als naam heeft dark.matt.er, en hij moet zijn output laten zien op light.Ik ga er van uit dat je op de remote computer (dark.matt.er) bent in gelogd.Als je csh draait op de remote computer:dark% setenv DISPLAY light.uni.verse:0 dark% xfig &of:dark% xfig -display light.uni.verse:0 &Als je sh of bash draait op de remote computer:dark$ DISPLAY=light.uni.verse:0 dark$ export DISPLAY dark$ xfig &of:dark$ DISPLAY=light.uni.verse:0 xfig &of:dark$ xfig -display light.uni.verse:0 &Het ziet er naar uit dat sommige versies van telnet automatisch het DISPLAY variabel gelijk goed zetten op de remote host. Als je er zo een hebt dan heb veel geluk en moet je het niet allemaal met de hand doen. Zo niet, de meeste versies van telnet trans porteren het TERM variabel; met een beetje hacken is het mogelijk om het DISPLAY variabele met het TERM variabel mee te laten komen. Het idee van het transporteren is een beetje scripting om het volgende te bereiken: voordat je telnet, bevestigen we het variabel DISPLAY aan TERM. Dan telnet op de remote host, in de .*shrc file, lees het variabel DISPLAY van TERM. De server vertellenDe server zal niet zomaar een connectie van iedereen accepteren. Je wilt toch niet dat iedereen zo maar een window op je scherm kan zetten. Of lezen wat je schrijft -- onthoud je keyboard is onderdeel van het display!Veel mensen schijnen zich niet te realiseren dat het toestaan van toegang tot je display een groot security risico is. Iemand met toegang to je display kan lezen van en schrijven naar je scherm, alles lezen wat je typt, en je muis acties registreren.De meeste servers kennen twee manieren voor het legaliseren van connecties naar de server: het host lijst mechanisme (xhost) en het magic cookie mechanisme (xauth). Dan is er ook nog ssh, de secure shell, die kan X connecties ook doorsturen.

XhostXhost laat connecties toe op hostnaam. De server houd een lijst bij van host die mogen connecten. Het kan ook host checking volledig uitschakelen. Onthoud: dat betekend dat er geen checks meer uitgevoerd worden, dus iedere host mag connecten!Je kan de servers host list bijhouden met het programmatje xhost. Om dit te gebruiken moet je het mechanisme uit het volgende voorbeeld gebruiken.light$ xhost +dark.matt.erDit staat connecties van de host dark.matt.er toe. Zodra je X client een connectie heeft gemaakt en een window weergeeft, schakel voor de veiligheid meer connecties uit met:light$ xhost -dark.matt.erJe kan host verificatie uitschakelen met:light$ xhost +Dit schakelt de host toegang verificatie uit en dus iedereen mag connecten. Je moet dit nooit doen op een netwerk waar je niet alle gebruikers vertrouwd (internet bijvoorbeeld). Je kunt host verificatie weer aanzetten met:light$ xhost -xhost - verwijderd niet alle host-Namen uit zichzelf van de toeganslijst (dat zou niet echt slim zijn - je kan dan niet meer connecten naar je Xserver van waar dan ook - zelfs niet vanaf localhost).Xhost is een zeer onveilig mechanisme. Het maakt geen onderscheid tussen verschillende gebruikers op de remote host. Ook host-Namen (eigenlijk adressen) kunnen gespoofd worden. Dit is vervelend als je op een onbetrouwbaar netwerk zit (internet bijvoorbeeld).
X Applicatie van een andere User-idStel dat je een grafische applicatie wilt draaien met root authenthificatie. Alhoewel je X sessie onder je eigen account draait. Op het eerste gezicht lijkt dit vreemd, maar de X server kan de tool toegang niet toestaan op jou display. Hoe is dit mogelijk, als de root normaal alles mag doen? en hoe ga je dit probleem oplossen ?Laat ons focussen op de situatie, je wilt een X applicatie onder een User-id clientuser, maar de X sessie is gestart door serveruser. Als je de sectie over cookies hebt gelezen, dan is het duidelijk waarom clientuser geen toegang krijgt tot jou display: ˜clientuser/.Xauthority heeft niet de goede magic cookie voor toegang tot de display. De goede cookie kun je vinden in ˜serveruser/.Xauthority.

Verschillende gebruikers op dezelfde HostAlles dat werkt voor remote X werkt natuurlijk ook voor X van een ander User-id (vooral slogin localhost -l clientuser). het is waar dat de client host en de server toevallig hetzelfde zijn. Alhoewel, als de hosts hetzelfde zijn, dan is er een kortere weg om de magic cookie te transporteren.We nemen aan dat jij gebruikt maakt van su om van User-id te wisselen. Wat je normaal kunt doen is een script schrijven om su aan te roepen, maar zet in het script dat su execute enkel de dingen die nodig zijn voor remote X. Dit zijn de DISPLAY variabele en de transfer van de magic cookie.Het vaststellen van het DISPLAY variabel het is best simpel; het betekend alleen het vaststellen van DISPLAY="$DISPLAY" voordat je het su commando optie start. Dus je kunt het zo doen:su - clientuser -c "env DISPLAY=$DISPLAY client-program &"Dit werkt nog niet, omdat we nog steeds de cookie moeten transporteren. We kunnen de cookie ophalen door middel van xauth list "$DISPLAY". Die commando gebeurd om de cookie in een format goed formaat te krijgen voor het terug sturen naar xauth; dat is wat we willen! Dus we sturen de goede cookie terug naar xauth in het su commando, het variabel DISPLAY daar, en het commando starten wat we willen.su - clientuser -c "xauth add `xauth list $DISPLAY`; \ exec env DISPLAY=$DISPLAY client-program"We kunnen een scripts rond dit alles schrijven met de volgende variabelen clientuser en client-program. Laten we het script een beetje verbeteren en het minder leesbaar maken. Het ziet eruit als dit:#!/bin/sh if [ $# -lt 2 ] then echo "usage: `basename $0` clientuser command" >&2 exit 2 fi CLIENTUSER="$1"; shift exec su - "$CLIENTUSER" -c "xauth add `xauth list \"$DISPLAY\"`; \ exec env DISPLAY='$DISPLAY' "'"$SHELL"'" -c '$*'"Ik denk dat het wel werkt in de meeste situaties. De enige tekort komming die ik met kan met nu kan indenken is dat, door het gebruik van '$*', single quotes in command zullen het su commando met argument ('$*') een beetje in de war brengen. Als je denk dat er iets echt mis is mail me.Roep het script aan /usr/local/bin/xsu, en je kunt doen:xsu clientuser 'command &'Makkelijk?, nee
Een Remote Window Manager draaienEen window manager (als twm, wmaker, of fvwm95) is een applicatie als elk ander. De normale procedure zou dus moeten werken.Vaak, in elk geval een window manager kan op elke tijd op een display draaien. Als je al een lokale window manager hebt draaien, dan kun je niet nog een remote starten (het wordt te ingewikkeld en stopt) je moet dan de lokale quiten of killen.Veel X sessie scripts eindigen ongelukkig met:exec window-manager-of-choiceEn dat betekend dat als de lokale window manager stopt, ook je sessie stopt. Het X systeem (xdm of xinit) neemt je sessie over en logt jou uit.Je moet een beetje moeite doen, maar het kan en het is niet echt moeilijk, speel eens wat met je session script (normaal ˜/.xsession of ˜/.xinitrc) om het voor elkaar te krijgen.Onthoud dat sommige window managers vaak de optie bieden om nieuwe programma's te starten en dat zal runnen op de lokale machine. Dat is, lokaal waar de window manager draait. Als je een remote window manager draait, zal het ook remote applicaties starten en dat is niet wat je wilt. Natuurlijk zullen ze wel verschijnen op wat voor jouw lokaal is.Problemen oplossenDe eerste keer dat je een remote applicatie probeert te draaien, is het normaal dat het niet werkt. Hier een paar normale fout boodschappen, en mogelijke oplossingen om je op weg te helpenxterm Xt error: Can't open display:Er is geen DISPLAY variabele in de omgeving, en je hebt de applicatie niet vertelt welke -display joker. De applicatie heeft een lege string aangenomen, maar dat is syntactisch niet goed. Om dit op te lossen moet je de goede DISPLAY omgevings variabele zetten (met setenv of export afhankelijk van je shell)._X11TransSocketINETConnect: Can't connect: errno = 101 xterm Xt error: Can't open display: love.dial.xs4all.nl:0Errno 101 is ``Network is unreachable''. De applicatie kan geen netwerk- connectie maken naar de server. Kijk of je de goede DISPLAY heb gezet, en of de server berijkbaar vanaf jou machine ( dit zou goed moeten wanneer je al op de server bent in gelogd en kan tel-netten naar de client)_X11TransSocketINETConnect: Can't connect: errno = 111 xterm Xt error: Can't open display: love.dial.xs4all.nl:0Errno 111 is ``Connection refused''. De server waar je naar probeert te connecten is bereikbaar, maar de desbetreffende server bestaat daar niet Kijk of je de goede host-naam gebruik en het goede display nummer.Xlib: connection to ":0.0" refused by server Xlib: Client is not authorized to connect to Server xterm Xt error: Can't open display: love.dial.xs4all.nl:0.0De client kan connectie maken met de server, maar de server geeft geen toestemming voor de client (niet geauthoriseerd). Weet je zeker dat je magic cookie goed hebt getransporteerd, en dat deze nog geldig is (de server gebruikt steeds een nieuwe cookie als er een nieuwe sessie wordt gestart).