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 su
dla 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 su
lub z powodu braku administratora użytkownika? Jak mogę zmusić tego użytkownika do uruchomienia aplikacji za pomocą GUI?
źródło
xauth list >/tmp/xa.$$; su - <otheruser> -c "unset XAUTHORITY; xargs xauth add </tmp/xa.$$"; rm -f /tmp/xa.$$
ale pamiętaj, że jest tam okropny stan wyścigu.su
chciał poprosić o hasło. Wypróbuj to nowe polecenie.W moim przypadku
wayland
problemem 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.źródło
xhost +
było wystarczająceSpróbuj czegoś takiego
źródło
Ps : zaakceptowana odpowiedź nie działała dla mnie
źródło
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/.Xauthority
na 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
-auth
jest 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).
źródło
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 plikchrome_debug.log
z 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/environ
i dokładniej zbadałem wynikistrace
procesu 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:
źródło
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
źródło
Po prostu wpisz to w swoim terminalu
xhost +SI:localuser:root
,export DISPLAY=:0.0
a następnie spróbuj ponownieźródło
Korzystając ze wskazówek w zaakceptowanych odpowiedziach, mogłem rozwiązać problem inaczej:
W kodzie:
źródło
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 :
Przetestuj serwer x:
Jeśli widzisz zegar pracujący, dobrze jest zacząć, teraz spróbuj uruchomić to:
Wynik powinien wyglądać tak:
Teraz pozwól user2 uzyskać dostęp do xhost
teraz spróbuj zalogować się ponownie do user2 i spróbuj otworzyć dowolny program GUI.
źródło