Uruchamianie aplikacji GUI jako inny użytkownik (inny niż root)

34

Załóżmy, że mam 2 konta użytkowników user1i user2. Kiedy loguję się jako user1, a następnie przełączam na user2używanie su, mogę uruchamiać programy wiersza polecenia, ale programy GUI zawodzą.

Przykład:

user1@laptop:~$ su - user2
user2@laptop:~$ leafpad ~/somefile.txt
No protocol specified
leafpad: Cannot open display: 

Jak mogę uruchomić aplikację GUI?

sashoalm
źródło
Odkryłem, że jednym z głównych powodów tego niepowodzenia jest to, że $XAUTHORITYwciąż jest ustawiony na user1 ~/.Xauthority, który program, jak sądzę, spróbuje odczytać, i nie powiedzie się, ponieważ ten plik zwykle ma tryb 0600 ( -rw-------), co oznacza, że ​​jest niedostępny do czytania przez kogokolwiek z grupy „innej”, w tym użytkownika2. Oznacza to, że chmod o+r ~/.Xauthority(jako użytkownik1) zhakujesz sobie drogę do rozwiązania tego problemu. Napisałem skrypt, który to pokazuje.
Braden Best

Odpowiedzi:

42

su vs. su -

Kiedy stajesz się innym użytkownikiem, którego zazwyczaj chcesz używać su - user2. Myślnik zmusi użytkownika 2 .bash_profiledo uzyskania źródła.

xhost

Dodatkowo musisz przyznać użytkownikom dostęp do twojego wyświetlacza. Jest to regulowane przez X. Możesz użyć tego polecenia, xhost +aby zezwolić innym użytkownikom na wyświetlanie GUI na pulpicie użytkownika 1.

UWAGA: Podczas uruchamiania xhost +będziesz chciał uruchomić to w powłoce należącej do user1.

WYŚWIETLACZ $

Kiedy staniesz się użytkownikiem2, może być konieczne ustawienie zmiennej środowiskowej $DISPLAY.

$ export DISPLAY=:0.0
slm
źródło
1
xhost +user2wciąż daje mi ten błąd xhost: bad hostname "user2". Poszukałem go i wydaje mi się, że muszę to zrobić, xhost +user2@laptopalbo xhost +user2@localhostnie jestem pewien, który. Potem mówi xhost +user2@localhost being added to access control list.
sashoalm
1
Ale nawet po dodaniu użytkownika xhosti określeniu export DISPLAY=:0.0, uruchomienie leafpadnadal daje mi No protocol specified leafpad: Cannot open display:i nie działa. Znalazłem ten link na linuxquestions.org/questions/linux-newbie-8/... , który mówi, że są jakieś magiczne ciasteczka i xauth. Czy przetestowałeś już, że te rzeczy działają na twoim komputerze? Może coś jest inaczej w mojej konfiguracji? Jestem na Debianie + LXDE.
sashoalm
1
Dzięki, xhost +działa i nic więcej nie wydaje się potrzebne (nie trzeba ustawiać $DISPLAY). Czy możesz zaktualizować swoją odpowiedź, a ja ją zaakceptuję?
sashoalm
5
Och, znalazłem coś. Na Fedorze 21 działa xhostdaje listę w formacie SI:localuser:USERNAME, więc xhost SI:localuser:user2powinno działać. Aha, a wyświetlenie użytkownika można znaleźć za pomocą w.
Wilf
7
xhost +pozwoli każdemu użytkownikowi na dowolnym hoście, który może połączyć się z twoim X-serwerem, uzyskać dostęp do twojego ekranu. xhost +SI:localuser:user2działa dla mnie na Debianie.
robartsd
9

Musisz udostępnić token uwierzytelniający użytkownikowi 1 (zakładając, że ~jest to dom użytkownika 1 ):

cat ~/.Xauthority | sudo -u user2 -i tee .Xauthority > /dev/null
użytkownik4674453
źródło
1
To jedyna odpowiedź, która zadziałała dla mnie (Ubuntu 14).
sudo
To rozwiązanie działa ładnie z poziomu komputera zdalnego (= klient X Win), podczas gdy rozwiązania xhost w innych odpowiedziach muszą być wykonywane na komputerze lokalnym (= serwer X Win).
Jpsy
Może być bezpieczniej używać, tee -aaby uniknąć blokowania wszelkich istniejących informacji  .Xauthority.
Scott
7

Możesz użyć przekazywania X11:

ssh -XY otheruser@localhost your-gui-program-name-here
Michael Franzl
źródło
To wspaniałe rozwiązanie. Najprostszy, jaki do tej pory przeczytałem. O wiele więcej osób zna ssh niż konfigurację x11.
Alexis Panagiotopoulos,
6

Możesz uruchomić aplikację od innego użytkownika. Uruchomię aplikację gimp od użytkownika 2, podczas gdy jestem zalogowany (GUI) z użytkownikiem 1:

$ xhost +
$ sudo su user2

(wprowadź hasło)

$ gimp

Cieszyć się :)

Antoni Stawrew
źródło
4
Jest to to samo, co przyjęta czteroletnia odpowiedź.
G-Man mówi „Przywróć Monikę”
czy możesz powiedzieć szybszy lepszy sposób?
Antoni Stawrew
Zawsze korzystałem z tej metody, ale nie działa ona dla mnie z Debianem i Xfce. ( korekta : to działa, ale muszę export DISPLAYnajpierw, jak mówi zaakceptowana odpowiedź)
giusti
po zakończeniu sesji dobrze będzie ją wyłączyć przez$ xhost -
Antoni Stavrev
4

Możesz spróbować użyć polecenia sux:

sux user2

sux zajmie się rzeczami dla Ciebie DISPLAY. Może być konieczne zainstalowanie go z:

sudo apt-get install sux

pod Debian / Ubuntu.

phil
źródło
4
suxnie jest już wysyłany przez Debian ani Ubuntu. Najlepszą alternatywą, jaką mogłem znaleźć, jest dodanie xhost SI:localuser:root(lub cokolwiek innego użytkownika), ~/.xprofileaby zezwolić na to na stałe lub używaćrunuser
stefanct
Do wersji Debian Stretch włącznie była gksu/ gksudoalternatywa, która działała dobrze. Będąc nadal w Sid, jest usuwany w Buster ze względów bezpieczeństwa.
Matija Nalis
0

Alternatywnie do suxbezpiecznego uruchomienia polecenia graficznego ( firefox-esrw przykładzie poniżej) jako $AUTHUSER( guestw przykładzie poniżej):

AUTHUSER=guest
AUTHSTRING=SI:localuser:${AUTHUSER}
xhost +${AUTHSTRING} > /dev/null
SUDO_ASKPASS=/usr/bin/ssh-askpass
export SUDO_ASKPASS
sudo -k --askpass -u ${AUTHUSER} /usr/bin/firefox-esr
xhost -${AUTHSTRING} > /dev/null
sudo -K

kod:

  1. daje guestużytkownikowi dostęp do bieżącego użytkownika $DISPLAYza pośrednictwemxhost +SI:localuser:guest
  2. używa ssh-askpassgraficznie, aby poprosić cię o hasło (możesz oczywiście sudoers(5) NOPASSWD:tego uniknąć, jeśli twoja polityka bezpieczeństwa uważa, że ​​jest w porządku. Możesz też użyć innych askpassprogramów lub podać je w plikach konfiguracyjnych ( sudo(8)szczegółowe informacje na ten temat --askpass)
  3. jeśli hasło jest prawidłowe (i masz uprawnienia sudoers(5)), uruchamia polecenie /usr/bin/firefox-esrjako inny użytkownik ( guest)
  4. po zakończeniu programu uprawnienia innego użytkownika ( guest) do uzyskania dostępu $DISPLAYzostaną cofnięte przezxhost -SI:localuser:guest
  5. na koniec sudo -Kusuwa hasło z pamięci podręcznej, więc następne wywołanie ssh-askpasspoprosi o hasło ponownie (zamiast używać hasła z pamięci podręcznej)

    Chociaż jest to niewiele więcej pracy niż co gksu(8)lub sux(8)zrobione, można go skryptować i jest znacznie bezpieczniejsze niż:

    • xhost + (każdy użytkownik będzie miał dostęp do twojego wyświetlacza graficznego, o ile działa)
    • czytelne ~ / .xauth przez innych użytkowników (nieograniczony dostęp tego użytkownika do twojego wyświetlacza)
    • what gksu/ suxdid (tymczasowa kopia ~/.Xauthority, która pozwoliła określonemu użytkownikowi skopiować MIT-MAGIC-COOKIE-1i kontynuować używanie twojego wyświetlacza nawet po zakończeniu gksu / sux (o ile nie zamknąłeś maszyny lub nie wylogowałeś się z ekranu - wygaszacze ekranu, hibernacja itp. nie zmieniły magii) ciastko).

ponieważ pozwoli to tylko jednemu użytkownikowi lokalnemu na dostęp do twojego wyświetlacza, a następnie tylko tak długo, jak długo polecenie zostanie uruchomione (po zakończeniu polecenia $AUTHUSERnie będzie już w żaden sposób uzyskiwać dostępu do twojego wyświetlacza).

Inną bezpieczną alternatywą jest ssh -X(bez -Yktórych rzeczywiście sprawia, że mniej bezpieczne! Zobaczyć ForwardX11Trustedw ssh_config(5)szczegóły), ponieważ jest łatwiejszy w użyciu, jeśli nie są skryptów, ale to wywołuje additinal napowietrznych (np. Jest to wolniejsze) i niektóre programy mogą nie działać poprawnie bez niebezpiecznych -Y .

Matija Nalis
źródło
-1

Musisz załadować interfejs instalacyjny jako użytkownik2 .

Spróbuj wykonać to:

Zaloguj się jako root :

sudo su

Przetestuj serwer x:

xclock

Jeśli widzisz zegar pracujący, dobrze jest zacząć, teraz spróbuj uruchomić to:

xhost

Wynik powinien wyglądać tak:

xhost SI:localuser:tri
# tri is my user name

Teraz pozwól user2 uzyskać dostęp do xhost

xhost +SI:localuser:user2

teraz spróbuj zalogować się ponownie do user2 i spróbuj otworzyć dowolny program GUI.

Zbierz 1018
źródło
(1) W tym pytaniu nie ma nic, co wymagałoby uruchomienia jako root, lub gdzie uruchomienie jako root jest korzystne. (1b) Jeśli cokolwiek, uruchomienie jako root może po prostu pomylić sprawy. (2) Rzadko (jeśli w ogóle) jest jakiś powód do korzystania sudo su. Użyj  sudolub  su; Wybierz jedno. (3) Pytanie zostało napisane w kategoriach  user1i  user2. Proszę wpisać odpowiedź w kategoriach  user1i  user2. (Rób czy nie, nie ma  tri.) (4) Twoja odpowiedź byłaby lepsza, gdyby zawierała wyjaśnienie  SI:localuser. ………………… Proszę nie odpowiadać w komentarzach; edytuj  swoją odpowiedź, aby była jaśniejsza i bardziej kompletna.
Scott