Deze mini-HOWTO is een handleiding over hoe te doen met remote X applicaties. Hij is geschreven om verschillende redenen.
xhost + hostname''of zelfs
``xhost +'' om X connecties toe te staan. Dit is belachelijk
onveilig, want er zijn betere methodes.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 http://www.xs4all.nl/~zweije/xauth.html. Het is ook altijd aanwezig op de Remote X Apps mini-HOWTO op http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps. Linux (mini-)HOWTOs zijn aanwezig op http of ftp van sunsite.unc.edu.
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 Vincent Zweije
Een vergelijkbaar document op WWW is ``What to do when Tk says that your display is insecure'', http://ce-toolkit.crd.ge.com/tkxauth/. Dit is geschreven door Kevin Kenny. 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 O'Reilly and Associates 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 http://ciac.llnl.gov/ciac/documents/ciac2316.html.
Kijk ook eens in de newsgroepen, zoals comp.windows.x,
comp.os.linux.x, en comp.os.linux.networking.
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 http://ccwf.cc.utexas.edu/~zvonler/dxpc/ of LBX http://www.ultranet.com/~pauld/faqs/LBX-HOWTO.html (ook bekent als LBX mini-HOWTO).
Je moet twee dingen doen om dit te volbrengen:
Het 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:0DISPLAY=localhost:4DISPLAY=:0Een 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.Het 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 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 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.er
Dit 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.er
Je 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).
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 -auth. Nadat, de server alleen
connecties vanaf clients toelaat met de zelfde cookie. Als de
cookie in ~/.Xauthority veranderd, de server zal de
verandering dan niet doorvoeren.
Nieuwere servers genereren cookies gelijk als clients er om vragen.
Cookies blijven nog steeds behouden binnenin de server; ze komen niet
terecht in ~/.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.
Als je xauth wilt gebruiken, moet je de X server starten met de optie
-auth authfile. Als je het startx script gebruikt, dan is dat goede
plaats om het te doen. Maak een authorization record net als hieronder in
je startx script.
Stukje uit /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
ftp://ftp.math.uio.no/pub/linux/. Als alternatief kun je ook
md5sum gebruiken om verschillende data (van, bijvoorbeeld /dev/urandom
of ps -axl) in cookie om te zetten:
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 -auth
gebruiken als de server start. Als je inlogd bent met xdm, dan zet xdm de
cookie in ~/.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
Als je de X server gestart hebt op de server host light.uni.verse
en je hebt je cookie in ~/.Xauthority, dan moet je de
cookie transporteren naar de client dark.matt.er.
Het makkelijkst is als je home dir op light en dark zijn gedeeld.
De ~/.Xauthority files zijn het zelfde, dus de cookie
wordt gelijk getransporteerd. Maar, er zit een addertje onder het gras:
als je een cookie voor :0 in de file zet dan denkt dark dat het
voor zichzelf is ipv voor light. Dus je moet de volledige host-naam gebruiken
als je de cookie maakt; Je kunt het niet weg laten. Je kunt dezelfde cookie
installeren voor :0 en light:0 met:
#!/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 -
~/.Xauthority
(xauth nlist :0).| rsh dark.matt.er).~/.Xauthority daar (xauth nmerge -).Notitie voor het gebruik van ${HOST}. Je moet de cookie transporteren
die samenhangt met local host. Een remote X applicatie zal het display value
:0 gebruiken op de remote machine, dat is niet wat je wilde!
Het is mogelijk dat rsh niet voor je werkt. Naast dat, heeft rsh ook een security probleem (gespoofde host namen). Als je niet wil of kan gebruik maken van rsh, kun je het ook handmatig transporteren, zoals dit:
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 TERM variabel of
DISPLAY variabel als je tel-net doet naar een remote host. Dit werk het
zelfde als het transporteren van het DISPLAY variabel met het TERM
variabel. Zie Sectie 5: De client vertellen.
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 localhost:D. X client
applicaties kunnen dit vertalen in host/unix:D voor het
doel om de cookie te ontvangen. Dat betekend dat de cookie voor localhost:D
in je ~/.Xauthority geen zin meer heeft.
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 http://www.cs.hut.fi/ssh/ , de ssh home page.
Wie weet er andere manieren voor legaliserings schema's of encrypted X connecties? Misschien kerberos?
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 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.
Alles 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
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 DISPLAY zetten, en XAUTHORITY naar ~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 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-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.
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 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:0
Errno 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: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).