Propiedad de .Xauthority transferida a root

De alguna manera, mientras jugaba con LightDM y Webkit Greeter, la propiedad del .Xauthorityarchivo en mi directorio de inicio se le dio al usuario raíz y no pude iniciar sesión porque no tenía los privilegios para bloquear el archivo.

Pude recuperar la propiedad del archivo y pude volver a iniciar sesión. (Después de varias horas de reinstalar LightDM y sus saludos)

Así que ahora todo vuelve a funcionar bien. Pero me gustaría saber cómo sucedió esto. ¿Es esto un error en LightDM o Webkit Greeter o algo más?

permissions login

— s3lph
fuente

Respuestas:

Casi seguro que no, no. Que o bien comenzar una sesión X como root (no sé cómo se las arregló eso) o utilizó simplemente toucho no escribió .Xauthoritycon sudo. Para más detalles, tendría que explicar lo que realmente estaba haciendo.

La próxima vez, no reinstales nada, solo elimina el ~/.Xauthorityarchivo, se volverá a crear automáticamente la próxima vez que inicies sesión:

sudo rm ~/.Xauthority

Luego inicie sesión normalmente.

— terdon
fuente

Para averiguar dónde estaba el problema, una vez corrí sudo startx, qué funcionó. Después de cambiar la propiedad del archivo, podría iniciar sesión nuevamente. Entonces, ¿comenzar X como root simplemente solucionó el problema original?

— s3lph

@the_Seppi no, al ejecutar sudo startx se inició una sesión X que era propiedad de root, que era el propietario .Xsessiony, por lo tanto, podía iniciar sesión. Luego cambió la propiedad que permitió que su usuario volviera a iniciar sesión. La próxima vez, simplemente elimine el archivo, como dije, se vuelve a crear automáticamente al iniciar sesión, no tiene sentido "arreglar" sus permisos.

— terdon

Pero lo arregló. Y no hice nada más para .Xauthority. Por cierto. ¿Cuál es el propósito de este archivo?

— s3lph

@the_Seppi sí, lo arregló. El .Xauthorityarchivo es básicamente un número mágico utilizado para identificar al propietario de una sesión X para que otras personas no puedan secuestrarlo. Si está ejecutando una sesión X y estoy conectado a la misma máquina, no podré acceder a su sesión X a menos que sea el propietario del .Xauthorityarchivo. Se crea cada vez que inicia sesión a menos que exista uno. Entonces, sí, cambiar los permisos para su usuario lo solucionará, pero simplemente lo eliminará.

— terdon

Tuve el mismo problema; Lo conseguí tratando de ejecutar startx como root después de intentar recuperarme de una actualización fallida que desactivó bluetooth. Llevo horas intentando recuperar la GUI. ¡Resulta ser Super Simple! Elimine todos los archivos de bloqueo .Xauthority, elimine el archivo .Xauthority y reinicie. <rant> Son pequeños secretos como este, que son tan difíciles de encontrar si no estás al tanto (o ha pasado demasiado tiempo desde que lo estabas), que actualmente hacen de Linux una mala elección para muchas personas que de otro modo podrían usarlo. </rant>

— hlongmore

También me pasó a mí. Creo que podría ser causado por correr

sudo graphic_application

en lugar de

gksudo graphic_application

para alguna aplicación (desconocida). Hay un párrafo en la página de ayuda de sudo sobre eso ... desplácese hacia abajo hasta "Sudo gráfico".

Vea también ¿Cuál es la diferencia entre "gksudo nautilus" y "sudo nautilus"?

— Rmano
fuente

Eso no debería afectar el .Xauthority, que se crea cuando se inicia la sesión X, no será tocado por posteriores lanzamientos de aplicaciones GUI.

— terdon

@terdon tienes razón --- a menos que uses startx o similar. Estaba jugando con Xnest cuando me mordió, probablemente un error del operador.

— Rmano