jak używać xauth do uruchamiania aplikacji graficznej przez innego użytkownika w systemie Linux

48

Moje zwykłe konto użytkownika to, powiedzmy, użytkownik 1. Utworzyłem osobnego użytkownika2 dla niektórych aplikacji x, które chciałbym uruchomić, będąc zalogowanym do x jako użytkownik1, ale w sposób, który uniemożliwi dostęp do odczytu / zapisu danych użytkownika1. Myślałem, że mogę użyć xauth i sudo / su na user2 z user1, aby uruchomić tę aplikację. Jak mam to zrobic? Nie jestem pewien, jak skonfigurować xauth.

linux sudo

— Phil
źródło

32

Aby używać xauth wybiórczo, uruchom użytkownika1:

xauth list|grep `uname -n`

Spowoduje to wydrukowanie wpisów autoryzacji klucza sześciokątnego. Państwo mogłoby mieć różne obrazy związane z tymi gospodarzami, jak również.

Jako użytkownik2 ustaw wyświetlacz (przyjmując domyślny przypadek):

DISPLAY=:0; export DISPLAY

Następnie uruchomić:

xauth add $DISPLAY . hexkey

Zanotuj kropkę po $ DISPLAY i przed kluczem sześciokątnym.

Gdy dostęp nie jest już potrzebny, jako użytkownik2 możesz uruchomić:

xauth remove $DISPLAY

— Randall
źródło

Problem 1: użytkownik2 nie ma .Xauthoritypliku w katalogu domowym użytkownika2. Problem 2: Jakoś iz jakiegoś powodu nie rozumiem, po tym su, XAUTHORITY przechowuje ścieżkę do pliku user1. Ale ten plik nie jest czytelny dla użytkownika2.

— Otheus

Wygląda na to, że zapomniałeś unset XAUTHORITY pod user2

— socketpair

jest hexkeyw xauth addpoleceniu taka sama jak od xauth listczy muszę stworzyć losową nowy?

— bonanza

bonanza: jest to jedyne wyjście z listy xauth.

— John Eikenberry

1

Innym sposobem na zrobienie tego jest coś w rodzaju ... „ekstrakt xauth - $ DISPLAY | sudo -iu steam xauth merge -”. W tym przypadku mam XAUTHORITY ustawiony w .profile, więc 'sudo -i' poprawnie ustawia ten zestaw.

— John Eikenberry

12

Wstawiłem .zshrclinię z export XAUTHORITY=~/.Xauthorityi teraz jestem w stanie wykonać sudo -E xcommand. Po wielu googlowaniach był to dla mnie najłatwiejszy sposób.

— kfl62
źródło

1

Zauważ, że ta procedura zwykle nie wymagałaby użycia sudo -E(i używanie -Ejest wyłączone w większości domyślnych instalacji), ponieważ normalnie domyślna sudoerskonfiguracja pozwala na XAUTHORITYprzekazanie zmiennej środowiskowej do sudo.

— Guss,

@Guss To nie wymaga -E . Można go ustawić jako zmienną, którą można przekazać i sugeruje to Red Hat lub Debian.

— Daniel C. Sobral

@ DanielC.Sobral - tak powiedziałem :-)

— Guss

@Guss Och, przepraszam. Jakoś odwróciłem każde zdanie, które napisałeś. :-)

— Daniel C. Sobral

Nadal nie działało dla mnie w systemie Mac OS X z zsh

— Sridhar Sarnobat

9

Zakładając, że debian lub ubuntu (powinny być podobne w Red Hat / SUSE).

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

— ehempel
źródło

+1 dobra odpowiedź, nie ma sensu wymyślać koła na nowo. Nawiasem mówiąc, sux robi głównie to, co sugeruje moja powyższa odpowiedź. Oczywiście jest bardziej wydajny i łatwiejszy w użyciu.

— sleske

Można zauważyć, że „sux” jest w rzeczywistości również prostym skryptem powłoki.

— Martin Mächler,

5

suxjest nieobsługiwany (i usunięty z repozytoriów Debiana / Ubuntu): packages.qa.debian.org/s/sux/news/20140101T172633Z.html

— Rob W

9

Po pierwsze: nie używaj xhost +, jest raczej niepewny (koc pozwala / odmawia).

Zamiast tego użyj mechanizmu X-Cookie:

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

Alternatywnie, jeśli masz suxzainstalowany, użyj go (patrz odpowiedź ehempela).

W obu przypadkach użytkownik2 użyje tajnego pliku cookie w .Xauthority w celu autoryzacji na serwerze X i nikt inny nie będzie miał do niego dostępu.

Uwagi:

W zależności od uprawnień do plików konieczne może być skopiowanie .Xauthority w inny sposób.
Zamiast kopiowania .Xauthoritymożesz także użyć xauthdo wyodrębnienia i skopiowania klucza autoryzacji (patrz odpowiedź Randalla). Jeśli w .Xauthoritypliku jest wiele kluczy, jest to bardziej selektywne; w przeciwnym razie jest to kwestia gustu.

— Śleske
źródło

tak, mam dostęp do roota na tym komputerze

— Phil

Jest to po prostu ręczne kopiowanie plików cookie Xauth poprzez dostęp do konta root. Nie różni się to od używania xauth, jak wyjaśnia Randall w (bieżącej) górnej odpowiedzi, z tym wyjątkiem, że kopiuje każdy plik cookie, który pokazywałaby „lista xauth”. Jest to więc mniej bezpieczne niż górna odpowiedź xauth, która dodaje tylko wybrane pliki cookie.

— John Eikenberry

@JohnEikenberry: To prawda, dziękuję za zwrócenie na to uwagi. Zaktualizowałem swoją odpowiedź.

— sleske

7

To rozwiąże problem dla wszystkich użytkowników:

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

— JMS
źródło

Właśnie to zrobiłem i działa świetnie, dzięki!

— Guss,

3

Jako root:

xhost local:yourusername

Gdzie twoja nazwa użytkownika to nazwa użytkownika :)

Następnie wykonaj su, ponieważ użytkownik xclockpowinien działać, jeśli jest zainstalowany

— ACV
źródło

2

To tylko hacki:

xauth + (niezabezpieczony)
ssh -X user2 @ localhost (brzydki)

powyżej myślę, że ma właściwe rozwiązanie.

— alex
źródło

ssh -Xjest bardzo prostym i eleganckim rozwiązaniem, niezależnym od przestarzałych / nieutrzymanych rzeczy gtk / kde (które wymagają zainstalowania większej liczby plików binarnych z bitem SUID ...).

— Stefan

2

Znalazłem coś, co działa dla mnie świetnie w KDE

kdesu -u username /path/to/program

— Phil
źródło

W części debianowej kde-cli-toolsi nie w, $PATHale w /usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu(oczywiście w zależności od architektury).

— Stefan

0

W ten sposób wykonane w suse / opensuse: http://www.novell.com/support/kb/doc.php?id=7003743

Wystarczy zmodyfikować /etc/pam.d/su, dodając opcję (pogrubienie):

sesja opcjonalna pam_xauth.so systemuser = 1

Następnie możesz przełączać za pomocą su bez -:

su user2

i uruchom aplikację graficznie.

— pojem
źródło

-1

W przypadku GNOME (i bez żadnego środowiska graficznego, używam go tylko z icewm) gksu:

gksu -u username program

— Matija Nalis
źródło

„gksu jest przestarzałe od lat”: bugs.debian.org/cgi-bin/bugreport.cgi?bug=867236

— Stefan

@Stefan zauważa, że ten błąd Debiana dotyczy założenia, że podniesienie uprawnień dla całego programu jest złym pomysłem, i że zamiast tego program powinien zostać zmodyfikowany, aby zamiast tego uruchamiał minimalne pomocniki z podwyższonymi uprawnieniami (przy użyciu PolicyKit). To pytanie (i moja odpowiedź) dotyczy zmniejszenia uprawnień, co jest zupełnie inną rzeczą i tak naprawdę dobrym pomysłem (na przykład do losowego przeglądania Mam skrót, który wykonuje firefox na mniej uprzywilejowanym koncie niż moje domyślne, więc każdy exploit może dotknij moich danych - i gksu (8) jest całkiem w porządku)

— Matija Nalis

Wszystko w porządku, ale używanie przestarzałego i nieobsługiwanego pliku binarnego SUID jest po prostu złe. Ta odpowiedź mogła być przydatna w przeszłości, ale już nie jest.

— Stefan