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.
