Własność .Xauthority przeniesiona na root

Jakoś podczas zabawy z LightDM i Webkit Greeter własność .Xauthoritypliku w moim katalogu domowym została przekazana użytkownikowi root i nie mogłem się zalogować, ponieważ nie miałem uprawnień do blokowania pliku.

Udało mi się odzyskać własność pliku i mogłem zalogować się ponownie. (Po kilku godzinach ponownej instalacji LightDM i jego pozdrowienia)

Więc teraz wszystko znowu działa dobrze. Ale chciałbym wiedzieć, jak to się stało. Czy to błąd w LightDM lub Webkit Greeter, czy coś innego?

permissions login

— s3lph
źródło

Odpowiedzi:

Prawie na pewno nie, nie. Albo rozpoczął sesję X jako root (nie wiem, jak udało ci to) lub po prostu używany touchlub inaczej napisał .Xauthorityo sudo. Aby uzyskać więcej informacji, musisz wyjaśnić, co właściwie robiłeś.

Następnym razem nie instaluj niczego, po prostu usuń ~/.Xauthorityplik, zostanie on ponownie utworzony automatycznie przy następnym logowaniu:

sudo rm ~/.Xauthority

Następnie zaloguj się normalnie.

— terdon
źródło

Aby dowiedzieć się, gdzie był problem, raz uciekłem sudo startx, co zadziałało. Po zmianie właściciela pliku mogłem zalogować się ponownie. Czy uruchomienie X jako root naprawiło pierwotny problem?

— s3lph

@ theSeppi nie, uruchomienie sudo startx rozpoczęło sesję X, której właścicielem był root, który był właścicielem, .Xsessionwięc mógł się zalogować. Następnie zmieniłeś własność, która pozwoliła twojemu użytkownikowi zalogować się ponownie. Następnym razem po prostu usuń plik, jak powiedziałem, jest on automatycznie odtwarzany przy logowaniu, nie ma sensu „naprawiać” jego uprawnień.

— terdon

Ale to naprawiło. I nie zrobiłem nic innego, jak .Xauthority. Btw. jaki jest cel tego pliku?

— s3lph

@ theSSpipi tak, naprawił to. .XauthorityPlik jest po prostu magiczna liczba używany do identyfikacji właściciela sesji X, tak aby inne osoby nie mogą go porwać. Jeśli prowadzisz sesję X i jestem zalogowany na tym samym komputerze, nie będę mógł uzyskać dostępu do Twojej sesji X, chyba że jestem właścicielem .Xauthoritypliku. Jest tworzony przy każdym logowaniu, chyba że istnieje. Tak, zmiana uprawnień dla użytkownika to naprawi, ale po prostu usunie.

— terdon

Miałem ten sam problem; dostałem to w ten sposób, próbując uruchomić startx jako root po próbie odzyskania po nieudanej aktualizacji, która wyłączyła bluetooth. Próbowałem godzinami odzyskać GUI. Okazuje się, że jest to bardzo proste! Usuń wszystkie pliki blokady .Xauthority, usuń plik .Xauthority i uruchom ponownie. <rant> To takie małe sekrety, które są tak trudne do znalezienia, jeśli nie wiesz (lub minęło dużo czasu, odkąd byłeś), które sprawiają, że Linux jest złym wyborem dla wielu ludzi, którzy mogliby z niego skorzystać. </rant>

— hlongmore,

To mi się też przydarzyło. Myślę, że może to być spowodowane bieganiem

sudo graphic_application

zamiast

gksudo graphic_application

dla niektórych (nieznanych) aplikacji. Na stronie pomocy sudo znajduje się akapit o tym ... przewiń w dół do „Graficznego sudo”.

Zobacz także Jaka jest różnica między „gksudo nautilus” a „sudo nautilus”?

— Rmano
źródło

Nie powinno to wpływać na to .Xauthority, że powstaje, gdy sesja X jest uruchamiana, nie zostanie dotknięta kolejnymi uruchomieniami aplikacji GUI.

— terdon

@terdon masz rację --- chyba że używasz startx lub podobnego. Bawiłem się Xnestem, kiedy mnie ugryzło, prawdopodobnie błąd operatora.

— Rmano