Remote X Apps mini-HOWTO

Remote X Apps mini-HOWTO Autheur:, Vertaler: , v, 19 November 1999 Deze mini-HOWTO beschrijft hoe je remote X applicaties kan draaien. Dit betekent 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. Introductie

Deze 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 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 documentatie Een 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 Een voorbeeld Je 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 theorie Het magische woord is Een display bestaat uit een host naam ( zoals host/unix:D.S betekend scherm /tmp/.X11-unix/XD listening (dus hij is alleen berijkbaar vanaf host/unix:D.S, waar De client vertellen Het client programma (Bijvoorbeeld je grafische applicatie) weet naar welk display hij moet connecten door te kijken naar het 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 De server vertellen De 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. Xhost Xhost 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 light$ xhost +dark.matt.er Dit staat connecties van de host light$ xhost -dark.matt.er Je kan host verificatie uitschakelen met: light$ xhost + Dit schakelt de host toegang verificatie uit en dus light$ xhost - xhost - verwijderd Xauth Xauth staat connectie toe aan iedereen die het juiste geheim weet. Zo'n geheim wordt authorization record genoemd, of magic cookie. Dit legalisatie schema is formeel genoemd MIT-MAGIC-COOKIE-1. De cookies voor verschillende displays staan samen is ˜/.Xauthority. Jouw ˜/.Xaurthority moet niet toegangkelijk zijn voor andere groepen en gebruikers. Het xauth programmatje houd deze cookies bij, vandaar de bijnaam xauth voor het schema. Bij het starten van een sessie, leest de server de cookie uit het bestand die aangegeven wordt door de optie ˜/.Xauthority veranderd, ˜/.Xauthority behalve als een client ze daar zet. Volgens David Wiggins: Een volgende plooi is toegevoegd aan X11R6.3 daar zou je in geīnteresseerd kunnen zijn. Via het nieuwe SECURITY extensie, kan de X server zelf nieuwe cookies genereren en terugplaatsen ad-hoc. Verder, de cookies kunnen on vertrouwd worden aan gesteld daarom worden applicaties met zulke cookies beperkt in hun handeling. Bijvoorbeeld, ze kunnen dan niet de invoer van muis en keyboard lezen, of de inhoud van windows, van andere vertrouwde gebruikers. Er is een nieuw sub commando gemaakt voor xauth om dit mogelijk te maken voor gebruik. Xauth heeft is duidelijk veiliger dan xhost. Je kan beperkte toegang voor bepaalde gebruikers en hosts instellen. Het struikelt niet over gespoofde adressen zoals xhost. En als je wilt kun je xhost er ook nog bij gebruiken. De Cookie maken Als je xauth wilt gebruiken, moet je de X server starten met de optie /usr/X11R6/bin/startx: mcookie|sed -e 's/^/add :0 . /'|xauth -q xinit -- -auth "$HOME/.Xauthority" Mcookie is een heel klein programmatje in het util-linux pakkage, hoofd site . Als alternatief kun je ook md5sum gebruiken om verschillende data (van, bijvoorbeeld /dev/urandom of dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q xinit -- -auth "$HOME/.Xauthority" Als je het startx script niet kunt aanpassen (omdat je geen root bent) ga dan naar je systeem administrator en vraag hem om dit te doen, of laat hem xdm starten. Als hij het niet kan of wil, dan maak je een ˜/.xserverrc script. Als je het script hebt, zal xinit het runnen ipv de echte X server. Dan kun je de echte X server starten vanuit het script met de goed opties natuurlijk. Om dat te doen, laat je ˜/.xserverrc de magic cookie regel gebruiken en dan de echte X server starten: #!/bin/sh mcookie|sed -e 's/^/add :0 . /'|xauth -q exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority" Als je xdm gebruikt om je X sessie bij te houden, kun je xauth gemakkelijk gebruiken. Zet het regeltje 'DisplayManager.authDir in /etc/X11/xdm/xdm-config. Xdm zal nu de optie ˜/.Xauthority voor je. Zie xdm(1) voor meer informatie. Bijvoorbeeld, mijn /etc/X11/xdm/xdm-config heeft de volgend regel: Display Manager.authDir: /var/lib/xdm De cookie transporteren Als je de X server gestart hebt op de server host ˜/.Xauthority, dan moet je de cookie transporteren naar de client ˜/.Xauthority files zijn het zelfde, dus de cookie wordt gelijk getransporteerd. Maar, er zit een addertje onder het gras: als je een cookie voor #!/bin/sh cookie=`mcookie` xauth add :0 . $cookie xauth add "$HOST:0" . $cookie exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority" Als de homedirectory's niet zijn gedeeld, kun je de cookie transporteren door middel van rsh, de remote shell: light$ xauth list "${HOST}:0" | rsh dark.matt.er xauth nmerge - Haal de cookie uit je locale ˜/.Xauthority ( Verplaats het naar dark.matt.er ( Zet het in ˜/.Xauthority daar ( Notitie voor het gebruik van light$ echo $DISPLAY :0 light$ xauth list $DISPLAY light/unix:0 MIT-MAGIC-COOKIE-1 076aaecfd370fd2af6bb9f5550b26926 light$ rlogin dark.matt.er Pass-word: dark% setenv DISPLAY light.uni.verse:0 dark% xauth add $DISPLAY . 076aaecfd370fd2af6bb9f5550b26926 dark% xfig & [15332] dark% log out light$ Zie ook rsh(1) en xauth(1) voor meer informatie Het is mogelijk om de cookie te transporteren met het De Cookie gebruiken Een X applicatie op dark.matt.er, zoals xfig, zal automatisch kijken in ˜/.Xauthority om zichzelf te legaliseren. Er is een klein probleem als je gebruikt host/unix:D voor het doel om de cookie te ontvangen. Dat betekend dat de cookie voor ~/.Xauthority Ssh Authorizatie records worden gezonden zonder encryptie. Als bang bent dat iemand je connectie afluistert, gebruik dan ssh, de secure shell. Het gebruikt X forwarding over geëncrypte connecties. En daarnaast is het geweldig op andere manieren. Het is een goede structurele toevoeging aan je systeem. Ga naar , de ssh home page. Wie weet er andere manieren voor legaliserings schema's of encrypted X connecties? Misschien kerberos? X Applicatie van een andere User-id Stel 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 Laat ons focussen op de situatie, je wilt een X applicatie onder een User-id ~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 Host Alles dat werkt voor remote X werkt natuurlijk ook voor X van een ander User-id (vooral We nemen aan dat jij gebruikt maakt van Het vaststellen van het 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 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 #!/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 Roep het script aan /usr/local/bin/xsu, en je kunt doen: xsu clientuser 'command &' Makkelijk?, nee Client gebruiker is Root Blijkbaar kan alles dat voor niet root client gebruikers werkt ook werken voor root. Alhoewel als root kun je het gemakkelijker maken , dit omdat de root iedereen zijn ~/.Xauthority file mag lezen. Het is niet nodig de cookie te transporteren. Het enigste dat je hebt te doen is het ~serveruser/.Xauthority. Dus je kan: su - -c "exec env DISPLAY='$DISPLAY' \ XAUTHORITY='${XAUTHORITY-$HOME/.Xauthority}' \ command" Als je hier een script van maakt, dan ziet het er ongeveer zo uit: #!/bin/sh if [ $# -lt 1 ] then echo "usage: `basename $0` command" >&2 exit 2 fi su - -c "exec env DISPLAY='$DISPLAY' \ XAUTHORITY='${XAUTHORITY-$HOME/.Xauthority}' \ "'"$SHELL"'" -c '$*'" Noem het script /usr/local/bin/xroot, en dan kun je: xroot 'control-panel &' Kan het nog eenvoudiger, nee? Een Remote Window Manager draaien Een window manager (als 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-choice En 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 oplossen De 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 helpen xterm Xt error: Can't open display: Er is geen _X11TransSocketINETConnect: Can't connect: errno = 101 xterm Xt error: Can't open display: love.dial.xs4all.nl:0 Errno 101 is ``Network is unreachable''. De applicatie kan geen netwerk- connectie maken naar de server. Kijk of je de goede _X11TransSocketINETConnect: Can't connect: errno = 111 xterm Xt error: Can't open display: love.dial.xs4all.nl:0 Errno 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.0 De 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).