Czy mogę uruchomić program graficzny na pulpicie innego użytkownika jako root?

Oto inne pytania, które moim zdaniem powinienem wiedzieć:

• Z sesji innej niż X? (co oznacza, że ​​root nie jest zalogowany w X)

• Jeśli na X zalogowanych jest wiele osób, czy mogę automatycznie wykryć, kto był na jakim ekranie, a tym samym programowo wykryć, na którym ekranie muszę uruchomić aplikację?

• Czy mogę uruchomić aplikację jako użytkownik? (ok, jestem na 99,999% pewien, że to tak)

• Czy mogę wykryć, czy użytkownicy z grupy X są zalogowani w X?

Aby uruchomić program graficzny na pulpicie użytkownika, musisz znaleźć dwie rzeczy: na jakim ekranie wyświetla się pulpit użytkownika (adres) i jakiego pliku cookie autoryzacji użyć (hasło).

Następujące polecenie powinno wyświetlić listę wyświetlaczy lokalnych, na których użytkownik jest zalogowany (po jednym w wierszu) w większości jednorożców:

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

Znalezienie pliku cookie autoryzacji jest nieco trudniejsze. Musisz poszukać pliku cookie użytkownika, który jest ~/.Xauthoritydomyślnie (wszystko czego potrzebujesz to lokalizacja pliku cookie, nie musisz go wyodrębniać). Działa to na wielu systemach, ale nie na wszystkich; zależy to od menedżera wyświetlania i jego konfiguracji, w szczególności Gdm (domyślny w Ubuntu) nie używał domyślnej lokalizacji podczas ostatniego wyszukiwania. Nie mogę wymyślić przenośnego sposobu na znalezienie rzeczywistego pliku cookie X. Najdokładniejszym sposobem sprawdzenia tego jest ustalenie pid procesu X i poszukiwanie argumentu -authopcji. Innym sposobem jest znalezienie procesu działającego na tym serwerze X i XAUTHORITYpobranie jego zmiennej środowiskowej. Jeśli masz problemy ze znalezieniem pliku cookie, zobaczOtwórz okno na zdalnym wyświetlaczu X (dlaczego „Nie można otworzyć wyświetlacza”)?

Po uzyskaniu obu informacji umieść wybrany ekran w DISPLAYzmiennej środowiskowej, wybrany plik cookie autoryzacji X w XAUTHORITYzmiennej środowiskowej i gotowe. Nie ma znaczenia, jakiego użytkownika uruchamia program; połącz z, sujeśli chcesz.

Nie mogę tego całkowicie wypróbować, ponieważ wszystkie moje maszyny mają wyłączony root.

Aby dowiedzieć się, który ekran jest włączony, możesz użyć whopolecenia. Ostatnią kolumną danych wyjściowych jest zwykle WYŚWIETLACZ, na którym użytkownik jest zalogowany. Coś takiego można wykorzystać do przechwycenia samego wyświetlacza (istnieje prawdopodobnie znacznie bardziej wydajny sposób, aby to zrobić, zachęcamy do zaoferowania edycji):

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

Następnie, aby uruchomić graficzne polecenie X na tym ekranie:

DISPLAY=:0 firefox &

gdzie: 0 zostanie zastąpione dowolnym wyświetleniem znalezionym w pierwszym poleceniu, a Firefox zostanie zastąpione dowolnym poleceniem, które chcesz uruchomić. Możesz umieścić to w skrypcie powłoki i po prostu użyć zmiennej.

Następna część to część, której nie testowałem, ale nie rozumiem, dlaczego nie powinno być to możliwe:

su username -c "DISPLAY=:0 firefox"

aby uruchomić polecenie X jako ten użytkownik.

Możesz spojrzeć na to, jak robi to ostry. Np. Kiedy wydaje polecenia xscreensaver lub pusto ekran dla każdego użytkownika uruchamiającego X lub X-sesję.

Na przykład w systemie Ubuntu ten plik zawiera powiązane rzeczy:

/etc/acpi/lid.sh

Zawiera tę pętlę:

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

Rozszerzenie odpowiedzi Gillesa polega na tym, jak znaleźć plik cookie. Jednym ze sposobów może to być po ustawieniu DISPLAYzmiennej środowiskowej (zgodnie z opisem Gillesa), użyj stracedo znalezienia xhostdostępu do plików . Mogę wymyślić coś takiego w BASH:

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

Dane wyjściowe powyższego kodu będą wyglądać następująco:

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

Jak wyraźnie widać, plik cookie pojawi się bezpośrednio tutaj.

Podczas moich badań nad znalezieniem eleganckiego sposobu wyświetlania GUI lub zadania X z ograniczonego środowiska, takiego jak reguły udev lub superużytkownik, niedawno stworzyłem narzędzie, które do niego pasuje ( więcej szczegółów ).

xpub to skrypt powłoki, aby uzyskać zmienne środowiska wyświetlania X dotyczące bieżącego lub danego TTY.

To jest przykład z regułą udev:

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

$env{ENV}: jeśli bieżący użytkownik tty uruchomi X, w przeciwnym razie usuń go.

Zasada jest taka sama w przypadku wiersza polecenia przy użyciu export:

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