Proprietà di .Xauthority trasferita a root

In qualche modo, mentre giocavo con LightDM e Webkit Greeter, la proprietà del .Xauthorityfile nella mia home directory veniva assegnata all'utente root e non potevo accedere perché non avevo i privilegi per bloccare il file.

Sono stato in grado di riguadagnare la proprietà del file e ho potuto accedere nuovamente. (Dopo diverse ore di reinstallazione di LightDM e dei suoi messaggi di benvenuto)

Quindi ora tutto funziona di nuovo bene. Ma vorrei sapere come è successo. È un bug in LightDM o Webkit Greeter o qualcos'altro?

permissions login

— s3lph
fonte

Risposte:

Quasi certamente no, no. O hai avviato una sessione X come root (non sei sicuro di come l'hai gestita) o semplicemente utilizzato toucho altrimenti scritto .Xauthoritycon sudo. Per maggiori dettagli, dovresti spiegare cosa stavi effettivamente facendo.

La prossima volta, non reinstallare nulla, basta eliminare il ~/.Xauthorityfile, verrà ricreato automaticamente al prossimo accesso:

sudo rm ~/.Xauthority

Quindi accedere normalmente.

— terdon
fonte

Per scoprire dove fosse il problema, una volta ho corso sudo startx, cosa ha funzionato. Dopo aver modificato la proprietà del file ho potuto accedere nuovamente. Quindi l'avvio di X come root ha risolto il problema originale?

— sabato

@the_Seppi no, l'esecuzione di sudo startx ha avviato una sessione X di proprietà di root, che era il proprietario di .Xsessione quindi poteva accedere. Quindi hai cambiato la proprietà che ha permesso al tuo utente di accedere nuovamente. La prossima volta, basta eliminare il file, come ho già detto, viene ricreato automaticamente all'accesso, inutile "correggere" le sue autorizzazioni.

— terdon,

Ma l'ha risolto. E non ho fatto altro per. Autorità. Btw. qual è lo scopo di questo file?

— sabato

@the_Seppi sì, è stato risolto. Il .Xauthorityfile è sostanzialmente un numero magico usato per identificare il proprietario di una sessione X in modo che altre persone non possano dirottarlo. Se stai eseguendo una sessione X e sono connesso alla stessa macchina, non sarò in grado di accedere alla tua sessione X se non sono il proprietario del .Xauthorityfile. Viene creato ogni volta che accedi a meno che non esista. Quindi sì, la modifica delle autorizzazioni per l'utente lo risolverà, ma lo eliminerà semplicemente.

— terdon,

Ho avuto lo stesso problema; mi è venuto in questo modo il tentativo di eseguire startx come root dopo aver tentato di recuperare da un aggiornamento fallito che disabilitava il bluetooth. Ho provato per ore a riavere la GUI. Risulta essere Super semplice! Elimina tutti i file di blocco .Xauthority, elimina il file .Xauthority e riavvia. <rant> Sono piccoli segreti come questo, che sono così difficili da trovare se non sei al corrente (o è passato troppo tempo da quando lo eri), che attualmente rendono Linux una cattiva scelta per molte persone che altrimenti potrebbero usarlo. </rant>

— hlongmore

È successo anche a me. Penso che potrebbe essere causato dalla corsa

sudo graphic_application

invece di

gksudo graphic_application

per alcune app (sconosciute). C'è un paragrafo nella pagina di aiuto di sudo su questo ... scorri verso il basso fino a "Sudo grafico".

Vedi anche Qual è la differenza tra "gksudo nautilus" e "sudo nautilus"?

— Rmano
fonte

Ciò non dovrebbe influire su .Xauthority, che viene creato all'avvio della sessione X, non verrà toccato dai successivi lanci di app GUI.

— terdon,

@terdon hai ragione --- a meno che non usi startx o simili. Stavo giocando con Xnest quando ne sono stato morso, probabilmente un errore dell'operatore.

— Rmano,