On Fri, Jan 01, 2021 at 07:52:40PM +0100, to...@tuxteam.de wrote: > On Fri, Jan 01, 2021 at 10:24:44AM -0700, Charles Curley wrote: > > On Thu, 31 Dec 2020 22:30:34 -0600 > > David Wright <deb...@lionunicorn.co.uk> wrote: > > > > > $ /bin/su - > > > Password: > > > ahost ~# xeyes -display :0.0 > > > Xlib: connection to ":0.0" refused by server > > > Xlib: Client is not authorized to connect to Server > > > Error: Can't open display: :0.0 > > > ahost ~# ln -s ~auser/.Xauthority .Xauthority > > > > Bingo! That, rather than copying .Xauthority, gave me a fix. > > Huh? That is strange. I mean: great it worked for you, but I'd > like to learn what is going on there :-)
What don't you understand? In order for an X client to run, it needs two pieces of information: the DISPLAY to talk to, and the authorization to be allowed to talk. For the authorization piece, the client looks for an MIT-magic-cookie in a file named by the XAUTHORITY variable, or if that variable isn't set, then it looks for the file $HOME/.Xauthority . By creating this symlink, David has forever tied root's ~/.Xauthority file to the one in auser's home directory. Whenever an X client running as root tries to run, in the absence of the XAUTHORITY variable, it will look at ~root/.Xauthority which is a symlink to ~auser/.Xauthority which is presumably on a local file system that root can read. So the client can read the MIT-magic-cookie, so it can authenticate itself to the X server, so it can run. This will fall on its face if some user other than auser happens to be the one who started the X session.
