On Mon 04 Jan 2021 at 07:32:44 (-0500), Greg Wooledge wrote: > 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 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.
That's right—this was for a single-user (auser) PC. It saved their having to remember to set the environment variable each time. The post was to discourage this user from running commands as root when there was no need—in that instance, starting ppp as root rather than adding themselves to dip and/or dialout. It also explained the reasons at length, because at that time there had been a succession of posts on the list demonstrating misunderstandings about the roles of root and users, and the "absolute power" of root to do anything. But here on debian-user, I was really more interested in why the value of DISPLAY was apparently changed by one su and not the other (or perhaps by both). The explanation, "probably with an alias for su", alias su="su -w DISPLAY", doesn't make any sense to me. Explanations? Cheers, David.
