Debian: logowanie do X-ów (DISPLAY, xhost, .Xauthority) i uruchamianie sesji graficznych
Any X client, by default, reads that file to see what the cookie is then sends it to the X server to authenticate itself.
Anyone who can read that file can access the display so that file normally only readable by the user who logged in, though root can always read it because root is god.
No, in fact, xhost needs the DISPLAY variable already set so that it knows which display to try and connect to change access control.
Any X client, by default, reads that file to see what the cookie is then sends it to the X server to authenticate itself.
xhost needs some way to authenticate itself to the X server so X can trust that it's a legit user trying to change the access control.
If you open up X to all local users by using something like xhost+localhost or xhost local: then any local user could take over your display and use xhost to disable your access to it.
local: allows anyone to access the X server through unix domain sockets.
+localhost allows all local programs to access X though tcp sockets.
Normally tcp sockets are only used for remote connections since they are slower than unix sockets, but unix sockets only work on the same machine.
Co dokładnie jest w .Xauthority i dlaczego „geany” nie ma znaczenia
When X first logs in to a user, it creates the .Xauthority file in that users home directory and fills it with a random string called a MIT-MAGIC-COOKIE.
By default, any X client reads that file to see what the cookie is then sends it to the X server to authenticate itself.
To tłumaczy zachowanie „aplikacja graficzna działa tak samo jakby jej nie było” - kluczowe nie jest to, czy uruchamiasz konkretnie „geany”, tylko z jaką konfiguracją dostępu (cookie) oraz jakim kontekstem środowiska uruchamiasz klienta X.
ale pomijając ten szkopuł to działa dobrze ale tylko w przypadku gdy istnieje jeden user, ten wymieniony w ścieżce.
Gdy chciałem utworzyć morfik2 i zalogować się tylko do systemu przez lightdm, to już mnie system nie chciał przepuścić.
Po zakomentowaniu tego wpisu, bez problemu mogłem się zalogować.
Jak .Xauthority wpływa na logowanie i uruchamianie aplikacji z roota
When you run an X program as a different user, it will look in that users home directory for the .Xauthority file and so won't be able to find the right cookie unless you used the xauth command to give that user the cookie ahead of time.
By setting the XAUTHORITY environment variable to some other file, it will check that file for the magic cookie instead of the current users home directory.
This is useful when running a command as root that you want to access an normal users X server.
This is a much more secure way to allow acces to X than using xhost since you know what users are able to access X, not just which computers, which may have multiple users on them.
In summary, don't touch xhost, just use:
XAUTHORITY=/home/user/.Xauthority xscreensaver
or you can use xauth to extract the magic cookie and then import it into the correct users .Xauthority file.
Przekazywanie cookie między użytkownikami (xauth extract/merge)
As the user of the X server: xauth extract my-cookie-file $DISPLAY
Saves the magic cookie to a file called my-cookie-file for the current display.
Then as the user who want to access the X display: xauth merge my-cookie-file
Adds the cookie stored in my-cookie file to the current users .Xauthority file.
Now user B can open an X application on A's X server.
Oh, and don't run xscreensaver as root EVER!
Instead, if you're really paranoid about security, make a user who can access any of your files whose sole purpose is to run xscreensaver then use that user to run it.
This is still not that much more secure since any user that can access an X server can essentially take it over and control your mouse and keyboard doing what ever they want, like openning an xterm on your display and running the passwd command to change your passwd. Now they just gained access to all your files as well.
Dlaczego cookie działa tylko „na czas zalogowania”
Problem w tym, że tylko na czas zalogowania się.
Widać ten cookie jest tworzony przy każdym zalogowaniu się na x-y przez jakiegoś usera i by mieć możliwość odpalania graficznych aplikacji z roota, trzeba by ciągle powtarzać kroki z wydobywaniem ciasteczka i dodawaniem go do .Xauthority w katalogu roota.
This is useful when running a command as root that you want to access an normal users X server.
By setting the XAUTHORITY environment variable to some other file, it will check that file for the magic cookie instead of the current users home directory.
To oznacza, że jeśli sesja X jest tworzona na nowo przy każdym logowaniu, to „magiczne ciasteczko” też jest nowe, więc automatycznie wymagane jest ponowne dostarczenie uprawnień (albo przez stałe ustawienie XAUTHORITY, albo przez ponowne xauth extract/merge).
Debian: logowanie do środowiska graficznego po aktualizacji (xfce, testing)
U mnie podobnie, XFCE, najnowszy testing po aktualizacji nie mogę się zalogować do x-ów.
Wpisuję w okno logowania login, hasło, chwilę mieli i z powrotem wyskakuje okienko logowania.
Próbowałem także na root'a, to samo.
Sprawdzałem dysk df -H, ale miejsca mam nadto, więc nie tu leży przyczyna.
sprawdziłem w ~/.xsession_errors, niestety nie wiele zapamiętałem, ale widzę że chyba chodzi o błąd z xorg.conf lub jeszcze ewentualnie o uprawienia do któregoś z folderów/plików, ale nie zapamiętałem nazwy.
Wczoraj, przed aktualizacją systemu wszystko pięknie działało, coś musiało się zepsuć po upgradzie.
Jak wiadomo wszystkie systemu biurkowe również te napędzane przez jądro Linux korzystają z ekranu logowania.
Dzisiaj przyszedł do mnie kolega Piotrek, który jest dość zaawansowanym użytkownikiem systemu Arch Linux, że się już poddaje z próbą naprawienia ekranu logowania.
Uruchamianie sesji X przez xinit i .xinitrc
np. Drugim krokiem jest stworzenie pliku ~/.xinitrc.
Dla innych środowisk lub menadżerów okien plik będzie wyglądał inaczej.
Trzecim i najważniejszym krokiem jest stworzenie pliku odpowiedzialnego za uruchomienie Xservera.
Potrzebujemy do tego programu xinit.
- Dla użytkowników powłoki zsh, czyli na przykład mnie. [ -x "$f" ] && .
Powyższy sposób jest używany przeze mnie do uruchamiania środowiska na netbooku lub serwerze, jeśli sobie klient zażyczy obsługi za pomocą powłoki graficznej.
Ejest to szybki i lekki sposób na uruchamianie, a za razem również co ważne w środowisku serwerowym bezpieczny.
Dla systemów opartych o sysv np. Niniejsza porada jest skierowana dla bardziej zaawansowanych użytkowników niż zaczynających swoją przygodę z systemem Linux.
Ręczne przełączenie na konsolę i start/stop usług (przydatne do diagnostyki)
U mnie, aby w konsoli na chwilę przełączyć się na konto roota, wystarczy komenda sudo -s (u Ciebie pewnie będzie to coś z su).
Jeśli natomiast chcesz uruchomić środowisko graficzne z poziomu roota, a jesteś teraz zalogowany jako zwykły użytkownik, musisz najpierw wyłączyć te "iksy".
Na Ubuntu wystarczy jedna z sześciu kombinacji: Ctrl-Alt-FX, gdzie FX to jeden z klawiszy funkcyjnych F1...F6.
Spowoduje to uruchomienie konsoli na całym ekranie.
Następnie należy wyłączyć "iksy" - polecenie /etc/init.d/gdm stop.
Zakładam, że korzystasz z GNOME.
z tym, że do momentu wpisania okna logowania X-y są uruchomione, więc może tu nie chodzi o sam xserver tylko bardziej o te uprawnienia?
Na drugim komputerze (z którego teraz piszę) też po aktualizacji nie chciał od razu wystartować użytkownik po zalogowaniu, minęła ok. minuta zanim poszedł.
Tylko jak to naprawić? Czy próbować, wg poradnika w przyklejonych - dpkg-reconfigure xserver-xorg czy czegoś jeszcze innego?
Z tym, że do momentu wpisania okna logowania X-y są uruchomione, więc może tu nie chodzi o sam xserver tylko bardziej o te uprawnienia?
sprawdziłem w ~/.xsession_errors ... widzę że chyba chodzi o błąd z xorg.conf lub jeszcze ewentualnie o uprawienia do któregoś z folderów/plików
„Wpis w /root/.zshrc działa, ale jak przy wielu użytkownikach?”
Dodając powyższy wpis w /root/.zshrc (może być i .bashrc, jestem w trakcie zmiany shella) userzy mogą się logować bezproblemowo, obaj mogą się logować na roota, przy czym tylko jeden z nich może odpalać aplikacje graficzne.
Niby fajna rzecz, tylko pytanie, a gdybym tak miał 100 użytkowników w systemie i 2 adminów? Jak 2+ użytkownikom zezwolić na używanie graficznych appsów na roocie?
To właśnie dlatego ważne jest, że „przy każdym zalogowaniu się na x-y ... cookie jest tworzony”, a więc statyczny wpis do .zshrc może działać tylko w ograniczonych warunkach (np. gdy istnieje jeden user w ścieżce).
When X first logs in to a user, it creates the .Xauthority file in that users home directory and fills it with a random string called a MIT-MAGIC-COOKIE.
When you run an X program as a different user, it will look in that users home directory for the .Xauthority file
By setting the XAUTHORITY environment variable to some other file, it will check that file for the magic cookie instead of the current users home directory.
W modelu „wielu użytkowników” rozwiązaniem jest przenoszenie/odświeżanie cookie per sesja, zamiast stałego „na sztywno jednego usera”.
Dlaczego nie polegać na xhost w scenariuszu wieloużytkownikowym
In summary, don't touch xhost, just use:
XAUTHORITY=/home/user/.Xauthority xscreensaver
or you can use xauth to extract the magic cookie and then import it into the correct users .Xauthority file.
This is a much more secure way to allow acces to X than using xhost since you know what users are able to access X, not just which computers, which may have multiple users on them.
And znowu: If you open up X to all local users by using something like xhost+localhost or xhost local: then any local user could take over your display and use xhost to disable your access to it.
Wtedy dostęp przestaje być „ściśle kontrolowany po cookie”, a staje się „otwartą bramą na dostęp lokalny”, co w realnym systemie (wiele kont) przestaje być bezpieczne.
Najważniejszy punkt praktyczny: co sprawdzać, gdy logowanie do X wraca do ekranu
sprawdziłem w ~/.xsession_errors ... widzę że chyba chodzi o błąd z xorg.conf lub jeszcze ewentualnie o uprawienia do któregoś z folderów/plików
Z tym, że do momentu wpisania okna logowania X-y są uruchomione, więc może tu nie chodzi o sam xserver tylko bardziej o te uprawnienia?
Tylko jak to naprawić? Czy próbować, wg poradnika w przyklejonych - dpkg-reconfigure xserver-xorg czy czegoś jeszcze innego?
Jak wiadomo wszystkie systemu biurkowe również te napędzane przez jądro Linux korzystają z ekranu logowania.
Dzisiaj przyszedł do mnie kolega Piotrek, który jest dość zaawansowanym użytkownikiem systemu Arch Linux, że się już poddaje z próbą naprawienia ekranu logowania.
Jeśli usługa menedżera ekranu jest po aktualizacji problematyczna, to w trybie diagnostycznym przydaje się przełączenie na konsolę (Ctrl-Alt-FX), potem wyłączenie usług i próba uruchomienia ścieżką xinit/.xinitrc.
np. Drugim krokiem jest stworzenie pliku ~/.xinitrc.
Trzecim i najważniejszym krokiem jest stworzenie pliku odpowiedzialnego za uruchomienie Xservera.
Potrzebujemy do tego programu xinit.
U mnie, aby w konsoli na chwilę przełączyć się na konto roota, wystarczy komenda sudo -s (u Ciebie pewnie będzie to coś z su).
Następnie należy wyłączyć "iksy" - polecenie /etc/init.d/gdm stop.
Zakładam, że korzystasz z GNOME.
Ejest to szybki i lekki sposób na uruchamianie, a za razem również co ważne w środowisku serwerowym bezpieczny.
Jeśli środowisko nie startuje po logowaniu, to to co rozstrzyga temat uprawnień i konfiguracji sesji, często będzie wynikiem ustawień Xauthority, błędów konfiguracyjnych i różnic w tym, jak menedżer ekranu uruchamia sesję.
Widać ten cookie jest tworzony przy każdym zalogowaniu się na x-y przez jakiegoś usera
więc do uruchomienia aplikacji graficznych (zwłaszcza z roota) kluczowe staje się właściwe dostarczenie cookie dla aktualnej sesji.
By setting the XAUTHORITY environment variable to some other file, it will check that file for the magic cookie instead of the current users home directory.
Uwaga dot. bezpieczeństwa: aplikacje graficzne na roocie
Oh, and don't run xscreensaver as root EVER!
Instead, if you're really paranoid about security, make a user who can access any of your files whose sole purpose is to run xscreensaver then use that user to run it.
This is still not that much more secure since any user that can access an X server can essentially take it over and control your mouse and keyboard doing what ever they want
like openning an xterm on your display and running the passwd command to change your passwd.
Now they just gained access to all your files as well.
To oznacza, że nawet jeśli używasz bezpieczniejszego mechanizmu cookie zamiast xhost, to dostęp do X nadal jest w praktyce bardzo silnym uprawnieniem.
tags: #debian #logowanie #do #xow
Popularne posty:
Tomasz Sanecki administrator
Informatyk z zawodu i zamiłowania. Od 2007r właściciel firmy Perfect Systems. Specjalista do spraw bezpieczeństwa IT, serwisu urządzeń elektronicznych, sieci komputerowych. Prywatnie mąż i ojciec dwójki dzieci. Pasjonat nowoczesnych technologii, motocykli oraz włoskiego espresso.
About the author