Als root das Display des Users nutzen
Zugriff auf X-Server
Wer nun versucht ein X-Programm zu starten wird bitter enttaeuscht werden, denn auch "root" darf nicht ohne weiteres einen fremden X-Server als Ausgabemedium missbrauchen - dies muss zuvor der User gestatten. Die eigenen "Schluessel" hierzu liegen in der Datei "~/.Xauthority", und koennen ueber "xauth list" eingesehen werden. Will nun ein anderer User (in diesem Fall "root") auf unseren X-Server zugreifen, so benoetigt er einen passenden Schluessel: Diesen kann der User mit dem Befehl "xauth extract schluessel $DISPLAY" in einer Datei (in diesem Beispiel "schluessel") abspeichern, und "root" mit dem Befehl "xauth merge schluessel" dauerhaft seiner "~/.Xauthority" hinzufuegen.
Doch noch immer kann kein X-Programm gestartet werden, denn diesem muss erst noch mitgeteilt werden, welches Display verwendet werden soll. Hierfuer sorgt die Shellvariable "DISPLAY" (vgl. "man X"), die "root" noch setzen muss (z.B. durch die Eingabe von "DISPLAY=:0.0; export DISPLAY"). Ein Beispiel, bei dem der Dateimanager "X-Files" mit Rootrechten in einer User-X-Session genutzt werden soll:
| jo@planet ~> xauth extract xauth_jo $DISPLAY | jo@planet ~> su - | Password: | root@planet:~> xauth merge /home/jo/xauth_jo | xauth: creating new authority file /root/.Xauthority | root@planet:~> DISPLAY=:0.0; export DISPLAY | root@planet:~> X-Files | Starting X-Files...
Will man diese Einstellungen nicht jedesmal neu vornehmen sondern automatisch setzen lassen, so bietet sich fuer die Shellvariable $DISPLAY des "Users root" die Datei "/root/.bashrc" an (sofern die Bash verwendet wird). Der Schluessel selber bleibt fuer kuenftige Sitzungen erhalten.
Da "root" jedoch die Daten des Users lesen kann, ist in diesem Fall ein Auslesen, Transportieren und Einfuegen des Schluessels nicht erforderlich - so ist es moeglich, statt dem Ex- und Importieren einfach die gesamte Datei "~/.Xauthority" des Users zu uebernehmen. Beispiel:
| jo@planet ~> su - | Password: | root@planet:~> cp /home/jo/.Xauthority /root/ | root@planet:~> DISPLAY=:0.0; export DISPLAY | root@planet:~> X-Files | Starting X-Files...
Weniger dramatisch als das Kopieren oder Importieren fremder Zugangsdaten ist das Setzen der Umgebungsvariablen "XAUTHORITY", die "root" einfach auf die ".Xauthority" des Users zeigen lassen kann. Allerdings muss bei dieser Methode die Variable bei jedem Wechsel zum Rootaccount erneut gesetzt werden (vgl. $DISPLAY):
| jo@planet ~> su - | Password: | root@planet:~> XAUTHORITY=/home/jo/.Xauthority; export XAUTHORITY | root@planet:~> DISPLAY=:0.0; export DISPLAY | root@planet:~> X-Files | Starting X-Files...
[1] Quelle: http://www.linuxhilfen.org/admin/macht_user.html
Die einfache Alternative
Den User zur Ausführung des Zielprogramms als "root" berechtigen. Dazu zunächst einmal "sudo" installieren, z.B. unter Debian-Systemen:
apt-get install sudo
Anschließend mit visudo dem Zieluser oder einer ganzen Gruppe das Recht geben, Programme als "root" auszuführen:
# So darf er alles ausführen: meinuser ALL=(ALL) ALL # So darf er nur "/usr/bin/X-Files" ausführen, ohne dazu sein eigenes # Kennwort zur Bestätigung eingeben zu müssen: meinuser ALL=(ALL)NOPASSWD:/usr/bin/X-Files
Anschließend kann er das Programm starten, ohne irgendwelche Verrenkungen mit dem X-Display machen zu müssen:
sudo X-Files
klappt aber nicht immer!
z. B. bei firestarter:
(firestarter:3393): Gtk-WARNING **: This process is currently running setuid or setgid.
This is not a supported use of GTK+. You must create a helper
program instead. For further details, see:
http://www.gtk.org/setuid.html
Refusing to initialize GTK+
- Ob und wie Du unter X mit setuid-Programmen Dein System verbosselst, ist natürlich Deine Privatangelegenheit. :-D --Martin 09:53, 24. Feb 2005 (CET)
- deswegen finde ich die Lösung mit Xauthority für manche Sachen schon angebracht und deshalb auch erwähnenswert! ;-) 10:33, 24. Feb 2005 (CET)
