Jak rozwiązać problem „Nie określono protokołu” dla użytkownika su

Próbuję użyć alternatywnego użytkownika (nie będącego administratorem) do uruchomienia oprogramowania graficznego w moim systemie. Ten alternatywny użytkownik został nazwany i otrzymał UID i GID w celu dopasowania do zdalnego użytkownika systemu o tej samej nazwie. Identyfikator UID to 500, więc uważam, że czyni to użytkownika „niezalogowanym”.

Zaczynając od Ubuntu zalogowanego na moim głównym koncie, otwieram terminal i sudla alternatywnego użytkownika. Następnie próbuję wykonać polecenie, aby uruchomić aplikację i otrzymać komunikat „Nie określono protokołu”.

Czy to z powodu UID <1000, z powodu sulub z powodu braku administratora użytkownika? Jak mogę zmusić tego użytkownika do uruchomienia aplikacji za pomocą GUI?

Problem nie występuje z powodu identyfikatora UID użytkownika. 500 jest w porządku jako UID, a ten UID nie czyni z niego użytkownika „niezalogowanego”, z wyjątkiem domyślnych ustawień niektórych menedżerów wyświetlania.

Komunikat o błędzie Nie określono protokołu brzmi jak komunikat o błędzie specyficzny dla aplikacji i jest to nieprzydatny, ale zgaduję, że błąd polega na tym, że aplikacja nie może skontaktować się z twoim wyświetlaczem X11, ponieważ nie ma uprawnień do zrobienia dlatego, że działa jako inny użytkownik. Aplikacje potrzebują „magicznego ciasteczka” (tajnego tokena), aby rozmawiać z serwerem X11, aby inne procesy w systemie działające pod innymi użytkownikami nie mogły przeszkadzać w wyświetlaniu, tworzyć okien i szpiegować naciśnięć klawiszy. Drugi użytkownik systemu nie ma dostępu do tego magicznego pliku cookie, ponieważ uprawnienia są ustawione tak, aby był dostępny tylko dla użytkownika, który uruchomił środowisko pulpitu (tak jak powinno być).

Spróbuj, działając jako oryginalny użytkownik, skopiować plik cookie X11 na inne konto:

su - <otheruser> -c "unset XAUTHORITY; xauth add $(xauth list)"

następnie uruchom aplikację. Konieczne może być również rozbrojenie XAUTHORITYw tej powłoce. To polecenie wyodrębnia magiczne ciasteczko ( xauth list) od głównego użytkownika i dodaje je ( xauth add) tam, gdzie inny użytkownik może je zdobyć.

W moim przypadku waylandproblemem był nowy serwer wyświetlania ,

po prostu zrób xhost + local:wtedy inni użytkownicy (np. root) mogą uruchamiać Programy w twojej sesji, połączenia sieciowe jednak nie będą dozwolone.

Jeśli chcesz zezwolić klientom z dowolnego hosta , możesz z niego korzystać xhost +bez podawania żadnego hosta. Jest to jednak niebezpieczne , lepiej byłoby po prostu określić hosty, dla których chcesz przyznać dostęp do swojej sesji.

Spróbuj czegoś takiego

$ export LOGIN_USER="Math"
$ su - $LOGIN_USER
$ sudo xhost local:$LOGIN_USER &>/dev/null

źródło

Ps : zaakceptowana odpowiedź nie działała dla mnie

Załóżmy, że chcesz brutalnej siły uzyskać połączenie z X ...

Załóżmy, że już uruchamiasz swoje polecenia na serwerze (gdzie działa X), w przeciwnym razie spraw, by najpierw działało, a następnie użyj 'ssh -X użytkownik @ serwer) od klienta;).

Może istnieć kilka sposobów uruchamiania poleceń xauth, na przykład możesz używać „sudo”, ale może to spowodować utratę lub zmianę zmiennych środowiskowych. Należy zachować następujące zmienne środowiskowe: DISPLAY i XAUTHORITY. Aby sprawdzić, czy tak jest, możesz uruchomić „echo $ XAUTHORITY” w taki sam sposób, jak uruchamiasz swoje polecenia, ale upewnij się, że nie rozwijasz zmiennych środowiskowych przed uruchomieniem tych poleceń. Na przykład spróbuj: sudo bash -c 'echo "$ XAUTHORITY"', aby zobaczyć, czym naprawdę jest XAUTHORITY po uruchomieniu sudo (jeśli zniknie, być może trzeba będzie coś dodać do pliku sudoers, patrz gdzie indziej).

Ostatecznie uruchom następujące polecenie jako użytkownik, z którym chcesz uzyskać dostęp, na serwerze:

xauth info

Spowoduje to wyświetlenie „pliku uprawnień”, który będzie używany (domyślnie /root/.Xauthority, dla roota lub coś w rodzaju /home/theuser/.Xauthority). Jeśli pokazuje poprawny plik .Xauthority, to nie musisz się martwić o zmienną środowiskową XAUTHORITY (tak naprawdę nie wiedziałbym, kiedy to nie będzie, z wyjątkiem sytuacji, gdy chcesz manipulować niestandardowym miejscem tego pliku ).

Usuń ten plik (jeśli w ogóle istnieje):

rm /root/.Xauthority

Zamień /root/.Xauthorityna właściwy plik XAUTHORITY dla twojej sprawy.

Odtwórz go ponownie, ale pusty (jest to potrzebne do wielu poleceń):

touch /root/.Xauthority

W tym momencie pojawi się błąd Brak protokołu , nawet jeśli wcześniej otrzymałeś Nieprawidłowy MIT-MAGIC-COOKIE-1 . Znajdź plik uprawnień, z którego korzysta obecnie serwer X:

ps aux | grep Xorg

Powinno to pokazywać coś takiego:

root 1153 0.0 1.0 149560 44464 tty7 Ss+ dec02 0:00 /usr/lib/xorg/Xorg -nolisten tcp -auth /var/run/sddm/{ef18c483-7891-4e82-80ef-2c8f9bd79711} -background none -noreset -displayfd 17 vt7

Nazwa pliku po -authjest potrzebna w następnym poleceniu. Uruchom jako root:

sudo xauth -f '/var/run/sddm/{ef18c483-7891-4e82-80ef-2c8f9bd79711}' list

Zawiera 32-cyfrowy klucz szesnastkowy. Na przykład dane wyjściowe mogą być:

hostname/unix:0 MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7

Użyj go do wygenerowania pliku .Xauthority (jako użytkownik, który musi się ponownie zalogować):

xauth add $DISPLAY MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7

zamień „c0eaf749aa252101a0f57d5087089db7” na to, co zostało zwrócone dla ciebie przez polecenie list. Teraz Twój .Xauthority powinien mieć rozmiar 51 bajtów i możesz połączyć się z serwerem X (ponownie).

Miałem ten błąd „Nie określono protokołu”, kiedy uruchomiłem instancję Selenium 3.3.1 ze skryptu upstart, a następnie użyłem sterownika Chrome w Selenium. Selenium działało jako ten sam użytkownik co X11, a zmienna środowiskowa powłoki DISPLAY została ustawiona poprawnie. Co ciekawe, ten błąd nie wystąpił, gdy korzystałem ze sterownika Firefox. Ustawienie zmiennej środowiskowej powłoki XAUTHORITY w skrypcie upstart, aby wskazywało wartość $ XAUTHORITY aktywnego użytkownika X11, naprawiło błąd sterownika Chrome.

Na marginesie, błąd „Nie określono protokołu” został dokładnie pochowany przez sterownik Chrome / Chrome i nie był łatwy do znalezienia. Zauważyłem, że Chrome wciąż tworzy katalogi na wzór /tmp/.org.chromium.Chromium.*, ale szybko znikają. Udało mi się zauważyć, że zawierają one plik chrome_debug.logz komunikatem „Nie można otworzyć wyświetlacza”. Uznałem, że jest to dość dziwne, ponieważ zweryfikowałem, że proces selenu miał prawidłowy WYŚWIETLACZ /proc/$pid/environi dokładniej zbadałem wyniki straceprocesu selenu, co ujawniło, że „nie określono protokołu”, co ostatecznie doprowadziło mnie do tego pytania.

Ten błąd można odtworzyć, wyłączając XAUTHORITY i próbując uruchomić klienta X11. Na przykład:

$ XAUTHORITY= xeyes
No protocol specified
Error: Can't open display: :0.0

To było proste. Problem dzieje się, gdy jesteś w głównym nasycić i chcą korzystać z gksu Wystarczy wyjść stan korzeni i spróbuj ponownie

Po prostu wpisz to w swoim terminalu xhost +SI:localuser:root, export DISPLAY=:0.0a następnie spróbuj ponownie

Korzystając ze wskazówek w zaakceptowanych odpowiedziach, mogłem rozwiązać problem inaczej:

1. Znajdź plik Xauth na koncie, które działa (Xauth1)
2. Znajdź plik Xauth na koncie, który tego nie robi (Xauth2)
3. Skopiuj Xauth1 do Xauth2
4. Zmień uprawnienia Xauth2

W kodzie:

root@45c4933a8f1a:~# xauth info
Authority file:       /headless/.Xauthority
<snip>
root@45c4933a8f1a:~# su OtherUser
OtherUser@45c4933a8f1a:/headless$ xauth info
Authority file:       /home/OtherUser/.Xauthority
<snip>
OtherUser@45c4933a8f1a:/headless$ exit
exit
root@45c4933a8f1a:~# cp /headless/.Xauthority /home/OtherUser/.Xauthority 
root@45c4933a8f1a:~# chown OtherUser:OtherUser /home/OtherUser/.Xauthority
root@45c4933a8f1a:~# su OtherUser

Powiedzmy, że próbujesz uzyskać dostęp do GUI jako użytkownik2 ( zwykły użytkownik ), a następnie 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.