Verder Terug Inhoud

7. 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 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.

7.1 Verschillende gebruikers op dezelfde Host

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

7.2 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 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?


Verder Terug Inhoud