Propriété de .Xauthority transférée à la racine

D'une manière ou d'une autre, en jouant avec LightDM et Webkit Greeter, la propriété du .Xauthorityfichier dans mon répertoire personnel a été donnée à l'utilisateur root et je n'ai pas pu me connecter car je n'avais pas les privilèges pour verrouiller le fichier.

J'ai pu retrouver la propriété du fichier et j'ai pu me reconnecter. (Après plusieurs heures de réinstallation de LightDM et de ses salutations)

Alors maintenant, tout fonctionne bien à nouveau. Mais j'aimerais savoir comment cela s'est produit. Est-ce un bogue dans LightDM ou Webkit Greeter ou autre chose?

permissions login

— s3lph
source

Réponses:

Non, certainement pas. Vous avez soit démarré une session X en tant que root (vous ne savez pas comment vous avez géré cela), soit simplement utilisé touchou écrit .Xauthorityavec sudo. Pour plus de détails, vous devrez expliquer ce que vous faisiez réellement.

La prochaine fois, ne réinstallez rien, supprimez simplement le ~/.Xauthorityfichier, il sera recréé automatiquement la prochaine fois que vous vous connecterez:

sudo rm ~/.Xauthority

Connectez-vous ensuite normalement.

— terdon
source

Pour trouver où était le problème, j'ai couru une fois sudo startx, ce qui a fonctionné. Après avoir changé la propriété du fichier, je pouvais me reconnecter. Le démarrage de X en tant que root a-t-il simplement résolu le problème d'origine?

— s3lph

@the_Seppi non, l'exécution de sudo startx a démarré une session X qui appartenait à root qui était le propriétaire de .Xsessionet pouvait donc se connecter. Vous avez ensuite changé le propriétaire qui a permis à votre utilisateur de se reconnecter. La prochaine fois, supprimez simplement le fichier, comme je l'ai dit, il est recréé automatiquement lors de la connexion, inutile de "fixer" ses permissions.

— terdon

Mais cela l'a réparé. Et je n'ai rien fait d'autre pour .Xauthority. Btw. quel est le but de ce fichier?

— s3lph

@the_Seppi oui, il l'a corrigé. Le .Xauthorityfichier est essentiellement un nombre magique utilisé pour identifier le propriétaire d'une session X afin que d'autres personnes ne puissent pas le détourner. Si vous exécutez une session X et que je suis connecté à la même machine, je ne pourrai accéder à votre session X que si je suis le propriétaire du .Xauthorityfichier. Il est créé chaque fois que vous vous connectez, sauf s'il en existe un. Donc, oui, changer les autorisations de votre utilisateur le corrigera, mais le supprimera tout simplement.

— terdon

J'ai eu ce même problème; cela a été fait par moi en essayant d'exécuter startx en tant que root après avoir tenté de récupérer à partir d'une mise à jour bâclée qui a désactivé le bluetooth. J'essaie depuis des heures de récupérer l'interface graphique. Il s'avère que c'est super simple! Supprimez tous les fichiers de verrouillage .Xauthority, supprimez le fichier .Xauthority et redémarrez. <rant> Ce sont de petits secrets comme celui-ci, si difficiles à trouver si vous n'êtes pas au courant (ou cela fait trop longtemps que vous ne l'êtes pas), qui font actuellement de Linux un mauvais choix pour de nombreuses personnes qui pourraient autrement l'utiliser. </rant>

— hlongmore

Ça m'est aussi arrivé. Je pense que cela pourrait être causé par la course

sudo graphic_application

au lieu de

gksudo graphic_application

pour une application (inconnue). Il y a un paragraphe dans la page d'aide de sudo à ce sujet ... faites défiler jusqu'à "Sudo graphique".

Voir aussi Quelle est la différence entre "gksudo nautilus" et "sudo nautilus"?

— Rmano
source

Cela ne devrait pas affecter le .Xauthority, qui est créé au démarrage de la session X, il ne sera pas touché par les lancements ultérieurs d'applications GUI.

— terdon

@terdon vous avez raison --- sauf si vous utilisez startx ou similaire. Je jouais avec Xnest quand j'en ai été mordu, probablement une erreur d'opérateur.

— Rmano