Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #230174 > unrolled thread

Bullseye: setting and using $DISPLAY after su -

Back to article view | Back to linux.debian.user

Contents

  Bullseye: setting and using $DISPLAY after su - Charles Curley <charlescurley@charlescurley.com> - 2020-12-31 23:00 +0100
    Re: Bullseye: setting and using $DISPLAY after su - <tomas@tuxteam.de> - 2020-12-31 23:10 +0100
      Re: Bullseye: setting and using $DISPLAY after su - Greg Wooledge <wooledg@eeg.ccf.org> - 2020-12-31 23:20 +0100
        Re: Bullseye: setting and using $DISPLAY after su - Charles Curley <charlescurley@charlescurley.com> - 2021-01-01 01:50 +0100
          Re: Bullseye: setting and using $DISPLAY after su - David Wright <deblis@lionunicorn.co.uk> - 2021-01-01 05:40 +0100
            [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su - Charles Curley <charlescurley@charlescurley.com> - 2021-01-01 18:50 +0100
              Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su - <tomas@tuxteam.de> - 2021-01-01 20:00 +0100
                Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su - Charles Curley <charlescurley@charlescurley.com> - 2021-01-01 22:30 +0100
                Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su - Greg Wooledge <wooledg@eeg.ccf.org> - 2021-01-04 13:40 +0100
                  Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su  - The Wanderer <wanderer@fastmail.fm> - 2021-01-04 13:50 +0100
                    Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su - Greg Wooledge <wooledg@eeg.ccf.org> - 2021-01-04 14:40 +0100
                      Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su - <tomas@tuxteam.de> - 2021-01-04 15:50 +0100
                  Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su - David Wright <deblis@lionunicorn.co.uk> - 2021-01-06 05:40 +0100
                    Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su - Greg Wooledge <wooledg@eeg.ccf.org> - 2021-01-06 13:40 +0100
                      Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su - David Wright <deblis@lionunicorn.co.uk> - 2021-01-06 17:30 +0100
                        Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su - Greg Wooledge <wooledg@eeg.ccf.org> - 2021-01-06 19:50 +0100
          Re: Bullseye: setting and using $DISPLAY after su - Greg Wooledge <wooledg@eeg.ccf.org> - 2021-01-04 13:30 +0100
            Re: Bullseye: setting and using $DISPLAY after su - Charles Curley <charlescurley@charlescurley.com> - 2021-01-04 19:20 +0100
        Re: Bullseye: setting and using $DISPLAY after su - <tomas@tuxteam.de> - 2021-01-01 10:20 +0100
      Re: Bullseye: setting and using $DISPLAY after su - Charles Curley <charlescurley@charlescurley.com> - 2021-01-01 02:00 +0100
    Re: Bullseye: setting and using $DISPLAY after su - Mark Neyhart <Mark.Neyhart@akleg.gov> - 2021-01-01 04:10 +0100

Page 1 of 2  [1] 2  Next page →

#230174 — Bullseye: setting and using $DISPLAY after su -

I am using Bullseye as updated to yesterday. It is my custom to log in
to XFCE as my regular user, then "su -" in order to run as root,
including GUI programs. In the process, in the past $DISPLAY has been
set.

I now find on bullseye that $DISPLAY is not being set. However, even if
I set DISPLAY manually or run 'su -w DISPLAY -', programs like xclock
complain that they cannot open the display.

How do I allow root to use the display?

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [next] | [standalone]

#230175

[Multipart message — attachments visible in raw view] — view raw

On Thu, Dec 31, 2020 at 02:50:18PM -0700, Charles Curley wrote:
> I am using Bullseye as updated to yesterday. It is my custom to log in
> to XFCE as my regular user, then "su -" in order to run as root,
> including GUI programs. In the process, in the past $DISPLAY has been
> set.
> 
> I now find on bullseye that $DISPLAY is not being set. However, even if
> I set DISPLAY manually or run 'su -w DISPLAY -', programs like xclock
> complain that they cannot open the display.
> 
> How do I allow root to use the display?

Most probably you have to copy  the user's [1] ~/.Xauthority file to
root's home.

Cheers

[1] on behalf of which the X server runs.

> Does anybody read signatures any more?

Yes, I do :)
 - t

[toc] | [prev] | [next] | [standalone]

#230177

On Thu, Dec 31, 2020 at 11:02:18PM +0100, tomas@tuxteam.de wrote:
> On Thu, Dec 31, 2020 at 02:50:18PM -0700, Charles Curley wrote:
> > I am using Bullseye as updated to yesterday. It is my custom to log in
> > to XFCE as my regular user, then "su -" in order to run as root,
> > including GUI programs. In the process, in the past $DISPLAY has been
> > set.
> > 
> > I now find on bullseye that $DISPLAY is not being set.

It's worth pointing out that even on buster, "su -" does in fact clear
the value of DISPLAY, which is not really a surprise, since you explicitly
requested a "clean" login session as the new user.  Perhaps you are
mis-remembering what you used to do.  Perhaps you used to use regular
"su" without the infernal Red Hat "-" option.

unicorn:~$ su
Password: 
root@unicorn:/home/greg# env | grep DISPLAY=
HOSTDISPLAY=unicorn:0
DISPLAY=:0
root@unicorn:/home/greg# exit
unicorn:~$ su -
Password: 
root@unicorn:~# env | grep DISPLAY=
root@unicorn:~# 

Quite a difference, eh?  Almost certainly this is not a thing that
has changed during bullseye's run as testing.

> > I set DISPLAY manually or run 'su -w DISPLAY -', programs like xclock
> > complain that they cannot open the display.
> > 
> > How do I allow root to use the display?
> 
> Most probably you have to copy  the user's [1] ~/.Xauthority file to
> root's home.

More typically, since root can usually read the user's files,[2] all
that's needed is to export the XAUTHORITY variable with the full pathname
of the user's .Xauthority file.

[2] Unless of course the user's home directory is on a network file system.

[toc] | [prev] | [next] | [standalone]

#230180

On Thu, 31 Dec 2020 17:15:40 -0500
Greg Wooledge <wooledg@eeg.ccf.org> wrote:

> It's worth pointing out that even on buster, "su -" does in fact clear
> the value of DISPLAY, which is not really a surprise, since you
> explicitly requested a "clean" login session as the new user.
> Perhaps you are mis-remembering what you used to do.  Perhaps you
> used to use regular "su" without the infernal Red Hat "-" option.

I still have a small herd of buster boxen available, and 'su -' is
exactly what I have been doing for at least a decade.

Also, if I want to run as root, I want access to all the rootty system
administrator things like fdisk and fsck. Plain vanilla su leaves one
with the unprivileged user's PATH.

> 
> unicorn:~$ su
> Password: 
> root@unicorn:/home/greg# env | grep DISPLAY=
> HOSTDISPLAY=unicorn:0
> DISPLAY=:0
> root@unicorn:/home/greg# exit
> unicorn:~$ su -
> Password: 
> root@unicorn:~# env | grep DISPLAY=
> root@unicorn:~# 

Also on buster:

charles@hawk:~$ su
Password: 
root@hawk:/home/charles# env | grep DISPLAY
DISPLAY=:0.0
root@hawk:/home/charles# exit
exit
charles@hawk:~$ su -
Password: 

Today is Setting Orange, the 73rd of The Aftermath, 3186. All Hail Discordia! 
root@hawk:~# env | grep DISPLAY
DISPLAY=:0
root@hawk:~# xclock &
[1] 3550
root@hawk:~# 

(xclock ran successfully.)

> 
> Quite a difference, eh?  Almost certainly this is not a thing that
> has changed during bullseye's run as testing.

Yup, quite a difference. But something has changed.


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#230184

On Thu 31 Dec 2020 at 17:49:02 (-0700), Charles Curley wrote:
> On Thu, 31 Dec 2020 17:15:40 -0500 Greg Wooledge wrote:
> 
> > It's worth pointing out that even on buster, "su -" does in fact clear
> > the value of DISPLAY, which is not really a surprise, since you
> > explicitly requested a "clean" login session as the new user.
> > Perhaps you are mis-remembering what you used to do.  Perhaps you
> > used to use regular "su" without the infernal Red Hat "-" option.
> 
> I still have a small herd of buster boxen available, and 'su -' is
> exactly what I have been doing for at least a decade.

Same here, since the 1990s. In fact, I posted this dialogue on the
Corel mailing list in March 2000:

  ahost!auser 14:13 ~
  $ echo $DISPLAY
  :0.0                                 <---- the name of the display
  ahost!auser 14:13 ~
  $ xeyes -display :0.0                <---- now I close the new window
  ahost!auser 14:13 ~
  $ /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
  ahost ~# xeyes -display :0.0         <---- now I close the new window
  ahost ~# logout
  ahost!auser 14:14 ~
  $ 

> Also, if I want to run as root, I want access to all the rootty system
> administrator things like fdisk and fsck. Plain vanilla su leaves one
> with the unprivileged user's PATH.
> 
> > 
> > unicorn:~$ su
> > Password: 
> > root@unicorn:/home/greg# env | grep DISPLAY=
> > HOSTDISPLAY=unicorn:0
> > DISPLAY=:0
> > root@unicorn:/home/greg# exit
> > unicorn:~$ su -
> > Password: 
> > root@unicorn:~# env | grep DISPLAY=
> > root@unicorn:~# 
> 
> Also on buster:
> 
> charles@hawk:~$ su
> Password: 
> root@hawk:/home/charles# env | grep DISPLAY
> DISPLAY=:0.0
> root@hawk:/home/charles# exit
> exit
> charles@hawk:~$ su -
> Password: 
> 
> Today is Setting Orange, the 73rd of The Aftermath, 3186. All Hail Discordia! 
> root@hawk:~# env | grep DISPLAY
> DISPLAY=:0
> root@hawk:~# xclock &
> [1] 3550
> root@hawk:~# 
> 
> (xclock ran successfully.)
> 
> > 
> > Quite a difference, eh?  Almost certainly this is not a thing that
> > has changed during bullseye's run as testing.
> 
> Yup, quite a difference. But something has changed.

Well, for a start, the value of DISPLAY changes for you—that's never
happened to me (though I realise they both point to the same place).

Whitelisting with -w should do nothing for you—knowing the display's
location doesn't authorise you to use it.

The only suggestions I can come up with are:

Look at these files on buster (has PAM been modified?):

$ TZ=America/Phoenix ls --full-time /etc/pam.d/su*
-rw-r--r-- 1 root root 2257 2019-01-10 01:30:43.000000000 -0700 /etc/pam.d/su
-rw-r--r-- 1 root root  137 2019-01-10 01:30:43.000000000 -0700 /etc/pam.d/su-l
-rw-r--r-- 1 root root   95 2020-02-02 00:41:42.000000000 -0700 /etc/pam.d/sudo
$ apt-cache policy util-linux
util-linux:
  Installed: 2.33.1-0.1
  Candidate: 2.33.1-0.1
  Version table:
 *** 2.33.1-0.1 990
        990 http://deb.debian.org/debian buster/main amd64 Packages
        100 /var/lib/dpkg/status
$ 

Is wayland involved? (I have no idea what you're able to do with
PAM, wayland, or with XFCE either.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#230200 — [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su -

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. 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/

[toc] | [prev] | [next] | [standalone]

#230203 — Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su -

[Multipart message — attachments visible in raw view] — view raw

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 :-)

> 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

[toc] | [prev] | [next] | [standalone]

#230210 — Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su -

[Multipart message — attachments visible in raw view] — view raw

On Fri, 1 Jan 2021 19:52:40 +0100
<tomas@tuxteam.de> 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/

[toc] | [prev] | [next] | [standalone]

#230322 — 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.

[toc] | [prev] | [next] | [standalone]

#230323 — Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su -

[Multipart message — attachments visible in raw view] — view raw

On 2021-01-04 at 07:32, Greg Wooledge wrote:

> 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:

>>> 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

[toc] | [prev] | [next] | [standalone]

#230326 — 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.

[toc] | [prev] | [next] | [standalone]

#230327 — Re: [SOLUTION] Re: Bullseye: setting and using $DISPLAY after su -

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#230367 — 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, 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 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.

[toc] | [prev] | [next] | [standalone]

#230375 — 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   amd64        miscellaneous 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.

[toc] | [prev] | [next] | [standalone]

#230386 — 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/msg00000.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.

[toc] | [prev] | [next] | [standalone]

#230391 — 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.

[toc] | [prev] | [next] | [standalone]

#230320

On Thu, Dec 31, 2020 at 05:49:02PM -0700, Charles Curley wrote:
> On Thu, 31 Dec 2020 17:15:40 -0500
> Greg Wooledge <wooledg@eeg.ccf.org> wrote:

> Also, if I want to run as root, I want access to all the rootty system
> administrator things like fdisk and fsck. Plain vanilla su leaves one
> with the unprivileged user's PATH.

Only since buster, and this is fixable.  Just create this file with this
content:

unicorn:~$ cat /etc/default/su
ALWAYS_SET_PATH yes


> > It's worth pointing out that even on buster, "su -" does in fact clear
> > the value of DISPLAY,

> Also on buster:

> charles@hawk:~$ su -
> Password: 
> 
> Today is Setting Orange, the 73rd of The Aftermath, 3186. All Hail Discordia! 
> root@hawk:~# env | grep DISPLAY
> DISPLAY=:0

Clearly you're doing something special in root's .profile -- at the
very least, you're running that ddate command.  Is it possible you're
also hard-coding something like 'export DISPLAY=:0' there?

> root@hawk:~# xclock &
> [1] 3550
> root@hawk:~# 
> 
> (xclock ran successfully.)

Is it possible you also hard-coded something like
'export XAUTHORITY=/home/charles/.Xauthority' in root's .profile?

[toc] | [prev] | [next] | [standalone]

#230337

On Mon, 4 Jan 2021 07:25:30 -0500
Greg Wooledge <wooledg@eeg.ccf.org> wrote:

> > Today is Setting Orange, the 73rd of The Aftermath, 3186. All Hail
> > Discordia! root@hawk:~# env | grep DISPLAY
> > DISPLAY=:0  
> 
> Clearly you're doing something special in root's .profile -- at the
> very least, you're running that ddate command.  Is it possible you're
> also hard-coding something like 'export DISPLAY=:0' there?
> 
> > root@hawk:~# xclock &
> > [1] 3550
> > root@hawk:~# 
> > 
> > (xclock ran successfully.)  
> 
> Is it possible you also hard-coded something like
> 'export XAUTHORITY=/home/charles/.Xauthority' in root's .profile?
> 

Good thoughts, both. But, no such luck. I also checked the /etc
equivalents, and others mentioned in man bash, and found none such.

However, in the course of doing that I noticed that .Xauthority is now
a regular file, owned by root:root and 0600, as it should be. The date
on it is earlier this morning, when I logged in via SSH from another
machine. With the su alias I described earlier, xclock works.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#230185

[Multipart message — attachments visible in raw view] — view raw

On Thu, Dec 31, 2020 at 05:15:40PM -0500, Greg Wooledge wrote:

[...]

> > Most probably you have to copy  the user's [1] ~/.Xauthority file to
> > root's home.
> 
> More typically, since root can usually read the user's files,[2] all
> that's needed is to export the XAUTHORITY variable with the full pathname
> of the user's .Xauthority file.

This will do too, of course.

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#230181

[Multipart message — attachments visible in raw view] — view raw

On Thu, 31 Dec 2020 23:02:18 +0100
<tomas@tuxteam.de> wrote:

> > 
> > How do I allow root to use the display?  
> 
> Most probably you have to copy  the user's [1] ~/.Xauthority file to
> root's home.

No go. But thanks for the thought.

I also tried moving .Xauthority aside, logging out of the regular
account, logging in as root (which would create a new one), logging
out, and logging back in again. No go.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web