Kann ich ein Grafikprogramm auf dem Desktop eines anderen Benutzers als root starten?

Es folgen weitere Fragen, die ich zu wissen glaube:

• Aus einer Nicht-X-Sitzung? (Das bedeutet, dass root nicht bei X angemeldet ist.)

• Wenn mehrere Personen bei X angemeldet waren, kann ich dann automatisch erkennen, wer sich auf welchem ​​Bildschirm befand, und so programmgesteuert ermitteln, auf welchem ​​Bildschirm die App gestartet werden muss?

• Kann ich die App als Benutzer starten? (Ok, ich bin mir zu 99,999% sicher, dass dies ein Ja ist.)

• Kann ich feststellen, ob Benutzer der Gruppe X bei X angemeldet sind?

Um ein grafisches Programm auf dem Desktop eines Benutzers zu starten, müssen Sie zwei Dinge feststellen: Auf welcher Anzeige befindet sich der Desktop des Benutzers (die Adresse) und welches Berechtigungs-Cookie (das Kennwort) verwendet werden soll.

Der folgende Befehl sollte die lokalen Anzeigen auflisten, bei denen der Benutzer auf den meisten Geräten angemeldet ist (eine pro Zeile):

who | awk -v user="$target_user" '$1 == user && $2 ~ "^:" {print $2}'

Das Finden des Autorisierungscookies ist etwas schwieriger. Sie müssen nach der Cookie-Datei des Benutzers suchen, die ~/.Xauthoritystandardmäßig festgelegt ist (alles, was Sie benötigen, ist der Speicherort der Cookie-Datei, Sie müssen das Cookie nicht daraus extrahieren). Das funktioniert auf vielen Systemen, aber nicht allen. Das hängt vom Display-Manager und seiner Einrichtung ab. Insbesondere hat Gdm (der Standard unter Ubuntu) nicht den Standardspeicherort verwendet, den ich zuletzt verwendet habe. Ich kann mir keine tragbare Methode vorstellen, um die eigentliche X-Cookie-Datei herauszufinden. Der genaueste Weg, dies herauszufinden, besteht darin, die PID des X-Prozesses herauszufinden und nach dem Argument für die -authOption zu suchen . Eine andere Möglichkeit besteht darin, einen Prozess zu finden, der auf diesem X-Server ausgeführt wird, und dessen XAUTHORITYUmgebungsvariable abzurufen. Wenn Sie Probleme haben, die Cookie-Datei zu finden, lesen SieÖffnen Sie ein Fenster auf einer Remote-X-Anzeige (warum "Anzeige kann nicht geöffnet werden")?

Sobald Sie über beide Informationen verfügen, fügen Sie die ausgewählte Anzeige in die DISPLAYUmgebungsvariable und die ausgewählte X-Authority-Cookie-Datei in die XAUTHORITYUmgebungsvariable ein. Es spielt keine Rolle, unter welchem ​​Benutzer das Programm ausgeführt wird. Kombinieren Sie mit, suwenn Sie möchten.

Ich kann dies nicht vollständig versuchen, da auf allen meinen Rechnern root deaktiviert ist.

Mit dem whoBefehl können Sie ermitteln, auf welcher Anzeige sich ein Benutzer befindet . Die letzte Spalte der Ausgabe ist normalerweise das DISPLAY, an dem der Benutzer angemeldet ist. So etwas könnte verwendet werden, um nur das Display zu erfassen (es gibt wahrscheinlich eine weitaus effizientere Methode, zögern Sie nicht, Änderungen anzubieten):

who | grep -m1 ^username.*\( | awk '{print $5}' | sed 's/[(|)]//g'

Dann, um einen grafischen X-Befehl auf dieser Anzeige zu starten:

DISPLAY=:0 firefox &

Dabei wird 0 durch die Anzeige ersetzt, die Sie im ersten Befehl gefunden haben, und Firefox wird durch den Befehl ersetzt, den Sie ausführen möchten. Sie können dies in ein Shell-Skript einfügen und einfach eine Variable verwenden.

Der nächste Teil ist der Teil, den ich noch nicht getestet habe, aber ich verstehe nicht, warum dies nicht möglich sein sollte:

su username -c "DISPLAY=:0 firefox"

um den X-Befehl als dieser Benutzer zu starten.

Sie könnten sehen, wie acpid es macht. ZB wenn es xscreensaver Befehle ausgibt oder den Bildschirm für jeden Benutzer, der X oder X-session ausführt, leer macht.

Zum Beispiel enthält diese Datei unter Ubuntu verwandte Sachen:

/etc/acpi/lid.sh

Enthält diese Schleife:

for x in /tmp/.X11-unix/*; do
    displaynum=`echo $x | sed s#/tmp/.X11-unix/X##`
    getXuser;
    if [ x"$XAUTHORITY" != x"" ]; then
        export DISPLAY=":$displaynum"
        grep -q off-line /proc/acpi/ac_adapter/*/state
        if [ $? = 1 ]
            then
            if pidof xscreensaver > /dev/null; then 
                su $user -c "xscreensaver-command -unthrottle"
            fi
        fi
        if [ x$RADEON_LIGHT = xtrue ]; then
            [ -x /usr/sbin/radeontool ] && radeontool light on
        fi
        if [ `pidof xscreensaver` ]; then
            su $user -c "xscreensaver-command -deactivate"
        fi
        su $user -c "xset dpms force on"
    fi
done

Eine Erweiterung von Gilles Antwort ist, wie man die Cookie-Datei findet. Möglicherweise können Sie nach dem Festlegen der DISPLAYUmgebungsvariablen (wie von Gilles beschrieben) straceden Dateizugriff suchen xhost. Ich kann mir so etwas in BASH vorstellen:

# Set the DISPLAY variable first
DISPLAY = :0.0
# Use strace on xhost
strace xhost 2>&1 | grep access

Die Ausgabe des obigen Codes sieht folgendermaßen aus:

access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
access("/home/someuser/.Xauthority", R_OK) = 0

Wie Sie deutlich sehen können, wird die Cookie-Datei direkt hier angezeigt.

Bei meiner Suche nach einer eleganten Methode zum Anzeigen von GUI- oder X-Aufgaben in einer eingeschränkten Umgebung, z. B. mit udev-Regeln oder vom Superuser, habe ich kürzlich ein dazu passendes Tool erstellt ( für weitere Details ).

xpub ist ein Shell-Skript zum Abrufen der Variablen der X-Anzeigeumgebung in Bezug auf das aktuelle oder ein bestimmtes TTY.

Dies ist ein Beispiel mit einer udev-Regel:

IMPORT{program}="/usr/bin/xpub", \
RUN+="/bin/su $env{XUSER} -c '/usr/bin/notify-send Hello'"

$env{ENV}: Wenn der aktuelle Benutzer X startet, entfernen Sie es andernfalls.

Das Prinzip ist dasselbe für eine Befehlszeile mit export:

export $(xpub) ; su ${XUSER} -c 'notify-send Hello'