Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su -
On Fri, Jan 01, 2021 at 07:52:40PM +0100, tomas@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 <deblis@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.
Reply to: