Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su -
On Wed, Jan 06, 2021 at 10:20:00AM -0600, David Wright wrote: > User's DISPLAY not revealed > > After su DISPLAY=:0.0 > > (exit) > > User's DISPLAY not revealed > > After su - DISPLAY=:0 Well, that's pretty clear evidence that they're hard-coding the equivalent of "export DISPLAY=:0" in one of the dot-files that "su -" reads but which "su" does not. The obvious candidate would be /root/.profile but there are many other possibilities, up to and including some bizarre pam_env.conf thing. > As I pointed out, these values will both succeed in pointing to the > same actual display (though I only tested that they both work on my > own display, called ":0"). But they are textually "DIFFERENT", so > they can't both be copied from the user's (unrevealed) value. Yup.
Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su -
On Wed 06 Jan 2021 at 07:35:08 (-0500), Greg Wooledge wrote: > On Tue, Jan 05, 2021 at 10:38:39PM -0600, David Wright wrote: > > 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? > > "su" will leave the DISPLAY variable intact, and "su -" will remove it. > I can see no evidence to the contrary, regardless of whether I'm using > the ALWAYS_SET_PATH config variable. > > The behavior is simple and consistent for me. And for me. The only difference from the output you posted is $ cat /etc/default/su cat: /etc/default/su: No such file or directory $ but that only affects PATH anyway. > If someone is seeing DIFFERENT behavior than this, they have yet to > demonstrate it for us. I thought the OP already had demonstrated it, in https://lists.debian.org/debian-user/2021/01/msg0.html where we have: User's DISPLAY not revealed After su DISPLAY=:0.0 (exit) User's DISPLAY not revealed After su - DISPLAY=:0 As I pointed out, these values will both succeed in pointing to the same actual display (though I only tested that they both work on my own display, called ":0"). But they are textually "DIFFERENT", so they can't both be copied from the user's (unrevealed) value. So what I sought was an explanation of the OP's transcript, not that of yours and mine. Cheers, David.
Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su -
On Tue, Jan 05, 2021 at 10:38:39PM -0600, David Wright wrote: > 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? "su" will leave the DISPLAY variable intact, and "su -" will remove it. I can see no evidence to the contrary, regardless of whether I'm using the ALWAYS_SET_PATH config variable. The behavior is simple and consistent for me. unicorn:~$ cat /etc/debian_version 10.7 unicorn:~$ dpkg -S /bin/su util-linux: /bin/su unicorn:~$ dpkg -l util-linux | tail -n1 ii util-linux 2.33.1-0.1 amd64miscellaneous system utilities unicorn:~$ cat /etc/default/su ALWAYS_SET_PATH yes unicorn:~$ echo "$DISPLAY" :0 unicorn:~$ su Password: root@unicorn:/home/greg# echo "$DISPLAY" :0 root@unicorn:/home/greg# exit exit unicorn:~$ su - Password: root@unicorn:~# echo "$DISPLAY" root@unicorn:~# vi /etc/default/su root@unicorn:~# cat /etc/default/su # ALWAYS_SET_PATH yes root@unicorn:~# logout unicorn:~$ su Password: root@unicorn:/home/greg# echo "$DISPLAY" :0 root@unicorn:/home/greg# exit unicorn:~$ su - Password: root@unicorn:~# echo "$DISPLAY" root@unicorn:~# If someone is seeing DIFFERENT behavior than this, they have yet to demonstrate it for us.
Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su -
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.
Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su -
On Mon, Jan 04, 2021 at 08:36:09AM -0500, Greg Wooledge wrote: > On Mon, Jan 04, 2021 at 07:48:03AM -0500, The Wanderer wrote: > > I parsed the preceding conversation as indicating that > > > > $ ln -sf /home/auser/.Xauthority /root/.Xauthority > > > > produced a setup that worked, but > > > > $ cp /home/auser/.Xauthority /root/.Xauthority > > > > produced one that didn't. That seems strange enough to me. > > Well, the copied cookie would only work for as long as the current X > session remains running. As soon as a new cookie is created for a > new session, the copy becomes stale. Yes, that makes sense. Missing context, of sorts. "Copying the X auth file" meant to me "copying freshly after each new X session". By this I was adding implicitly some context which didn't necessarily match reality. Thanks, Greg :) Cheers - t signature.asc Description: Digital signature
Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su -
On Mon, Jan 04, 2021 at 07:48:03AM -0500, The Wanderer wrote: > I parsed the preceding conversation as indicating that > > $ ln -sf /home/auser/.Xauthority /root/.Xauthority > > produced a setup that worked, but > > $ cp /home/auser/.Xauthority /root/.Xauthority > > produced one that didn't. That seems strange enough to me. Well, the copied cookie would only work for as long as the current X session remains running. As soon as a new cookie is created for a new session, the copy becomes stale.
Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su -
On 2021-01-04 at 07:32, 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: >>> 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. I parsed the preceding conversation as indicating that $ ln -sf /home/auser/.Xauthority /root/.Xauthority produced a setup that worked, but $ cp /home/auser/.Xauthority /root/.Xauthority produced one that didn't. That seems strange enough to me. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su -
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.
Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su -
On Fri, 1 Jan 2021 19:52:40 +0100 wrote: > > > 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 :-) I quite agree. Someone else will have to answer that. We will see if it continues to work -- or continues to be necessary -- across multiple installations. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/ pgpnHBnGxsVRu.pgp Description: OpenPGP digital signature
Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su -
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 :-) > Thank you. > Now to automate carrying $DISPLAY over. Probably with an alias for su: > > alias su="su -w DISPLAY" > > > > Whitelisting with -w should do nothing for you—knowing the display's > > location doesn't authorise you to use it. > > True, but that gets $DISPLAY set up for root. Alternatively you can tweak your /etc/security/pam_env.conf (or $HOME/.pam_environment). See man pam_env(7) and man pam_env.conf(5) for details. Cheers - t signature.asc Description: Digital signature
[SOLUTION] Re: Bullseye: setting and using $DISPLAY after su -
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. Thank you. Now to automate carrying $DISPLAY over. Probably with an alias for su: alias su="su -w DISPLAY" > Whitelisting with -w should do nothing for you—knowing the display's > location doesn't authorise you to use it. True, but that gets $DISPLAY set up for root. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
