XauthXauth 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.
De Cookie makenAls 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 . 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
De cookie transporterenAls 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 home directories 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
(xauth nlist :0).
Verplaats het naar dark.matt.er (| rsh dark.matt.er).
Zet het in ˜/.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 informatieHet 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.
De Cookie gebruikenEen 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.