Wie verwende ich xauth, um eine grafische Anwendung über einen anderen Benutzer unter Linux auszuführen?

48

Mein reguläres Benutzerkonto ist beispielsweise user1. Ich habe einen separaten Benutzer2 für eine x-Anwendung erstellt, die ich ausführen möchte, während ich bei x als Benutzer1 angemeldet bin, aber auf eine Weise, die den Lese- / Schreibzugriff auf Benutzer1-Daten verhindert. Ich dachte, dass ich xauth und sudo / su zu Benutzer2 von Benutzer1 verwenden könnte, um diese Anwendung auszuführen. Wie mache ich das? Ich bin nicht sicher, wie ich xauth konfigurieren soll.

linux sudo

— Phil
quelle

32

So verwenden Sie xauth selektiv als Benutzer1:

xauth list|grep `uname -n`

Dadurch werden die Hexkey-Berechtigungseinträge für Sie gedruckt. Sie können auch verschiedene Anzeigen mit diesen Hosts verknüpfen.

Als Benutzer2 stellen Sie Ihre Anzeige ein (Standardfall vorausgesetzt):

DISPLAY=:0; export DISPLAY

Dann renne:

xauth add $DISPLAY . hexkey

Beachten Sie den Punkt nach dem $ DISPLAY und vor dem Hexkey.

Wenn der Zugriff nicht mehr benötigt wird, können Sie als Benutzer2 Folgendes ausführen:

xauth remove $DISPLAY

— Randall
quelle

Problem 1: Benutzer2 hat keine .XauthorityDatei im Ausgangsverzeichnis von Benutzer2. Problem 2: Irgendwie und aus irgendeinem Grund verstehe ich nicht, nachdem suXAUTHORITY den Dateipfad für Benutzer1 gespeichert hat. Diese Datei kann jedoch nicht von Benutzer2 gelesen werden.

— Otheus

Scheint, du hast es unset XAUTHORITY unter user2

— socketpair

ist der hexkeyim xauth addbefehl der selbe wie von xauth listoder muss ich einen zufälligen neuen erstellen?

— Bonanza

bonanza: dies ist die Ausgabe von xauth list.

— John Eikenberry

1

Ein anderer Weg, dies zu tun, wäre so etwas wie ... "xauth extract - $ DISPLAY | sudo -iu steam xauth merge -". In diesem Fall habe ich XAUTHORITY in .profile gesetzt, damit das 'sudo -i' diese Einstellung richtig macht.

— John Eikenberry

12

Ich habe .zshrceine Zeile mit export XAUTHORITY=~/.Xauthorityund jetzt kann ich ausführen sudo -E xcommand. Nach vielem googeln war das für mich der einfachste Weg.

— kfl62
quelle

1

Beachten Sie, dass für dieses Verfahren normalerweise keine Verwendung erforderlich ist sudo -E(und die Verwendung -Ebei den meisten Standardinstallationen deaktiviert ist), da normalerweise sudoersdie XAUTHORITYUmgebungsvariable in der Standardkonfiguration an sudo übergeben werden kann.

— Guss

@Guss Es ist nicht erforderlich -E . Es kann als Variable festgelegt werden, die übergeben werden kann, und entweder Red Hat oder Debian schlagen dies vor.

— Daniel C. Sobral

@ DanielC.Sobral - das habe ich gesagt :-)

— Guss

@Guss Oh, sorry. Ich habe irgendwie jeden Satz, den du geschrieben hast, umgekehrt. :-)

— Daniel C. Sobral

Funktionierte immer noch nicht für mich, auf Mac OS X mit zsh

— Sridhar Sarnobat

9

Angenommen, Debian oder Ubuntu (sollte unter Red Hat / SUSE ähnlich sein).

sudo apt-get install sux
sux user -c 'command'

— ehempel
quelle

+1 gute Antwort, kein Grund, das Rad neu zu erfinden. Übrigens macht sux meistens das, was meine Antwort oben nahelegt. Es ist natürlich leistungsfähiger und einfacher zu bedienen.

— sleske

Sie können feststellen, dass 'sux' in der Tat auch ein einfaches Shell-Skript ist.

— Martin Mächler

5

suxist nicht gepflegt (und wurde aus den Debian / Ubuntu-Repositories entfernt): packages.qa.debian.org/s/sux/news/20140101T172633Z.html

— Rob W

9

Erstens: Verwenden Sie es nicht xhost +, es ist eher unsicher (pauschal erlauben / verweigern).

Verwenden Sie lieber den X-Cookie-Mechanismus:

su user2
cp /home/user1/.Xauthority /home/user2/.Xauthority 
export DISPLAY=:0

Alternativ, wenn Sie suxinstalliert haben, verwenden Sie dies (siehe ehempels Antwort).

In beiden Fällen verwendet Benutzer2 das geheime Cookie in .Xauthority, um eine Autorisierung für den X-Server vorzunehmen, und kein anderer Benutzer hat Zugriff darauf.

Anmerkungen:

Abhängig von Ihren Dateiberechtigungen müssen Sie .Xauthority möglicherweise auf andere Weise kopieren.
Anstatt zu kopieren .Xauthority, können Sie auch xauthden Autorisierungsschlüssel extrahieren und kopieren (siehe Randalls Antwort). Wenn Sie mehrere Schlüssel in der .XauthorityDatei haben, ist dies selektiver. sonst ist es Geschmackssache.

— sleske
quelle

Ja, ich habe Root-Zugriff auf diese Maschine

— Phil

Dies ist nur manuelles Kopieren der xauth-Cookies über den Root-Zugriff. Dies unterscheidet sich nicht von der Verwendung von xauth, wie Randall in der (aktuellen) Top-Antwort erklärt, mit der Ausnahme, dass jedes Cookie kopiert wird, das in der 'xauth-Liste' angezeigt wird. Dies ist also weniger sicher als die obere xauth-Antwort, bei der nur die von Ihnen ausgewählten Cookies hinzugefügt werden.

— John Eikenberry

@ JohnEikenberry: Stimmt, danke für den Hinweis. Ich habe meine Antwort aktualisiert.

— sleske

7

Dies wird das Problem für alle Benutzer beheben:

cat <<EOF > /etc/profile.d/xauth.sh
#!/sbin/bash
export XAUTHORITY=~/.Xauthority
EOF

— JMS
quelle

Dies ist im Grunde, was ich getan habe und es funktioniert großartig, danke!

— Guss

3

Als root:

xhost local:yourusername

Wobei Ihr Benutzername Ihr Benutzername ist :)

Dann tun Sie so, wie Ihr Benutzer arbeiten xclocksollte, wenn es installiert ist

— ACV
quelle

2

Dies sind nur Hacks:

xauth + (unsicher)
ssh -X user2 @ localhost (hässlich)

sleske oben hat, denke ich, die richtige lösung.

— Alex
quelle

ssh -Xist eine sehr einfache und elegante Lösung, die nicht von veralteten / nicht mehr gepflegten gtk / kde-Inhalten abhängt (die die Installation weiterer Binärdateien mit SUID-Bit erfordern ...).

— Stefan

2

Ich habe etwas gefunden, das für mich in KDE hervorragend funktioniert

kdesu -u username /path/to/program

— Phil
quelle

Auf Debian-Seite von kde-cli-toolsund nicht in, $PATHsondern in /usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu(offensichtlich abhängig von der Architektur).

— Stefan

0

Auf diese Weise erstellt in suse / opensuse: http://www.novell.com/support/kb/doc.php?id=7003743

Ändern Sie einfach /etc/pam.d/su und fügen Sie die Option hinzu (fett):

session optional pam_xauth.so systemuser = 1

Dann können Sie mit su wechseln ohne -:

su user2

und starte die App grafisch.

— Gedicht
quelle

-1

Für GNOME (und ohne Desktop-Umgebung verwende ich es nur mit icewm) gksu:

gksu -u username program

— Matija Nalis
quelle

"gksu ist seit Jahren veraltet": bugs.debian.org/cgi-bin/bugreport.cgi?bug=867236

— Stefan

@Stefan beachte, dass dieser Debian-Fehler die Voraussetzung ist, dass das Erhöhen von Berechtigungen für das gesamte Programm eine schlechte Idee ist, und dass das Programm stattdessen so geändert werden sollte, dass nur minimale Helfer mit erhöhten Berechtigungen ausgeführt werden (mithilfe von PolicyKit). Bei dieser Frage (und meiner Antwort) geht es um das Reduzieren von Berechtigungen, was insgesamt eine andere Sache und in der Tat eine gute Idee ist (zum Beispiel habe ich für das zufällige Browsen eine Verknüpfung, die Firefox unter einem weniger privilegierten Konto ausführt, als mein Standardkonto, also kann jeder Exploit dort nicht meine Daten berühren - und gksu (8) ist ganz in Ordnung dafür)

— Matija Nalis

Das ist alles in Ordnung, aber die Verwendung einer veralteten und nicht mehr gepflegten SUID-Binärdatei ist einfach falsch. Diese Antwort mag in der Vergangenheit nützlich gewesen sein, ist aber nicht mehr.

— Stefan