11

Somehow, while playing around with LightDM and Webkit Greeter, the ownership of the .Xauthority file in my home dir was given to the root user and I couldn't login because I hadn't the privilegues to lock the file.

I was able to regain ownership of the file and I could login again. (After several hours of reinstalling LightDM and it's greeters)

So now everything's working fine again. But I'd like to know how this happened. Is this a bug in LightDM or Webkit Greeter or something else?

s3lph
  • 14,314
  • 11
  • 59
  • 82

2 Answers2

11

Almost certainly not, no. You either started an X session as root (not sure how you managed that) or simply used touch or otherwise wrote .Xauthority with sudo. For more details, you'd have to explain what you were actually doing.

Next time, don't reinstall anything, just delete the ~/.Xauthority file, it will be recreated automatically next time you log in:

sudo rm ~/.Xauthority

Then log in normally.

terdon
  • 100,812
  • To find where the problem was I once ran sudo startx, what worked. After changing the ownership of the file I could login again. So did starting X as root just fix the original problem? – s3lph Mar 20 '14 at 14:58
  • @the_Seppi no, running sudo startx started an X session which was owned by root who was the owner of .Xsession and so could log in. You then changed the ownership which allowed your user to log in again. Next time, just delete the file, as I said, it is recreated automatically on login, no point in "fixing" its permissions. – terdon Mar 20 '14 at 15:02
  • But it fixed it. And I didn't do anything else to .Xauthority. Btw. what's the purpose of this file? – s3lph Mar 20 '14 at 15:03
  • 1
    @the_Seppi yes, it fixed it. The .Xauthority file is basically a magic number used to identify the owner of an X session so that other people can't hijack it. If you are running an X session and I am logged in to the same machine, I won't be able to access your X session unless I am the owner of the .Xauthority file. It is created whenever you log in unless one exists. So yes, changing the permissions to your user will fix it but so will simply deleting it. – terdon Mar 20 '14 at 15:08
  • I had this same issue; it got that way by me trying to run startx as root after trying to recover from a botched update that disabled bluetooth. I've been trying for hours to get the GUI back. It turns out to be Super Simple! Delete all the .Xauthority lock files, delete the .Xauthority file, and restart. It's little secrets like this, that are so hard to find if you're not in the know (or it's been too long since you were), that currently make linux a poor choice for many people who could otherwise use it. – hlongmore Dec 05 '18 at 13:59
3

It happened to me too. I think that it could be caused by running

sudo graphic_application

instead of 

gksudo graphic_application

for some (unknown) app. There is a paragraph in the sudo help page about that... scroll down to "Graphical sudo".

See also What is the difference between "gksudo nautilus" and "sudo nautilus"?

Community
  • 1
Rmano
  • 31,947
  • That should't affect the .Xauthority, that is created when the X session is started, it won't be touched by subsequent launches of GUI apps. – terdon Mar 20 '14 at 15:52
  • @terdon you're right --- unless you use startx or similar. I was playing with Xnest when I was bite by it, probably operator error. – Rmano Mar 20 '14 at 16:03