From: Jean Christophe ANDR? (jean-christophe.andre@auf.org)
To: debian-security@lists.debian.org
Subject: allowing X display from su'd environment
Organization: Agence universitaire de la Francophonie / Bureau Asie-Pacifique / +H? Ni - Vit Nam
Date: Sat, 9 Nov 2002 12:40:12 +0700

Yogesh Sharma wrote:

>> I am using woody + testing + some unstable:
>> in xterm/gnome-terminal usually I do (as normal user) xhost +

Matt Zimmerman ?crivait :
> This disables access control in the X server. This is, almost always,
> a very bad idea.

A better way to allow it (when you switch from normal to root user) :

test@localhost:~$ su -
root@localhost:~# xauth merge ~test/.Xauthority
root@localhost:~# export DISPLAY=:0.0
root@localhost:~# xterm #or whatever Xwindow program you want to run

I can remember there was some 'su' feature doing it automagically somewhere (with Red Hat, Mandrake or another one)...

Cheers, J.C.

From: Matt Zimmerman (mdz@debian.org)
To: debian-security@lists.debian.org
Subject: Re: allowing X display from su'd environment
Date: Sat, 9 Nov 2002 10:41:05 -0500

An easier wethod:

$ su
# export XAUTHORITY=~user/.Xauthority

From: Michael Eyrich eyrich@ee.tu-berlin.de
To: debian-security@lists.debian.org
Subject: Re: allowing X display from su'd environment
Organization: Telecommunication Networks Group (TKN), TU Berlin, Germany
Date: Sat, 9 Nov 2002 17:00:23 +0100

On Sat, Nov 09, 2002 at 10:41:05AM -0500, Matt Zimmerman wrote:

| An easier wethod:
|
| $ su
| # export XAUTHORITY=~user/.Xauthority

This won't work, if ~user is NFS-mounted with the 'root_squash'-option, because 'nobody' won't be allowed to read ~users .Xauthority.

Regards,
Michael

From: Matt Zimmerman (mdz@debian.org)
To: debian-security@lists.debian.org
Subject: Re: allowing X display from su'd environment
Date: Sat, 9 Nov 2002 11:32:14 -0500

It also won't work if SE Linux or RSBAC access controls forbid root from reading this file, or if the user's X authority tokens are not in ~/.Xauthority, or any number of other reasons. The point was that it is simple. Anyone running a largish multiuser system with NFS-mounted home directories already understands these issues. Others are asking questions.

From: Rick Moen (rick@linuxmafia.com)
To: debian-security@lists.debian.org
Subject: Re: XFree86 4.2 bug in Debian Testing
Date: Sat, 9 Nov 2002 02:02:49 -0800

It's a little simpler to do:

$ ssh -X root@localhost

From: Martin Fluch (fluch@rock.helsinki.fi)
To: debian-security@lists.debian.org
Subject: Re: XFree86 4.2 bug in Debian Testing
Date: Sat, 9 Nov 2002 13:36:25 +0200 (EET)

Even easier: the following lines in the /root/.bashrc do the same trick:

if [ ! "$LOGNAME" = "root" ]; then
export XAUTHORITY=/home/$LOGNAME/.Xauthority
fi

And then su works without any problem (and computational overhead as the ssh solution).

Cheers,
- Martin

From: J?rg Sch?tter (joerg@schuetter.org)
To: debian-security@lists.debian.org
Subject: Re: XFree86 4.2 bug in Debian Testing
X-Mailer: Sylpheed version 0.8.5claws56 (GTK+ 1.2.10; )
Date: Sat, 9 Nov 2002 14:12:08 +0100

On Sat, 9 Nov 2002 13:36:25 +0200 (EET)
Martin Fluch (fluch@rock.helsinki.fi) wrote:

> Even easier: the following lines in the /root/.bashrc do the same
> trick:
>
> if [ ! "$LOGNAME" = "root" ]; then
> export XAUTHORITY=/home/$LOGNAME/.Xauthority
> fi

This solution doesn't work with "su -"

> And then su works without any problem (and computational overhead as
> the ssh sollution).

You can decrease the "overhead" with ssh -c des -X root@localhost

Gru?
J?rg

From: Christian Jaeger (christian.jaeger@ethlife.ethz.ch)
To: debian-security@lists.debian.org
Subject: Re: su and x (was Re: XFree86 4.2 bug in Debian Testing)
Date: Sat, 9 Nov 2002 14:36:01 +0100

Try http://fgouget.free.fr/sux/sux-readme.shtml

chj

RM adds: Very similar to "sux" are GKsu and kdesu, from the GNOME and KDE suites, respectively. Also gksudo, calife, chiark-really, gnome-sudo, and xsu.

From: Peter Cordes (peter@llama.nslug.ns.ca)
To: debian-security@lists.debian.org
Subject: Re: XFree86 4.2 bug in Debian Testing
Date: Mon, 11 Nov 2002 17:06:57 -0400

On Fri, Nov 08, 2002 at 05:28:52PM +0100, Ivan Brezina wrote:

> Another possibility is:
> su -c vim-gtk
>
> you can also use xhost +username for allowing users to connect to our
> Xserver. But this does not work for me on Debian.

xhost is host based access control, so of course xhost +username doesn't work! Debian by default starts X servers with -nolisten tcp, so doing xhost + (to allow all connections) is the same as xhost +localhost, and is ok if (and only if) there are no local users you don't absolutely trust (including trusting them not to get their accounts cracked with bad passwords).

I emphatically do not recommend using ssh running X stuff as root. That is huge overhead compared to unix sockets and shared memory! (If it's working fine for you, then whatever, do what's easiest for you, but if you're going to go to the trouble of learning how to jump through a hoop to get X working, pick the right hoop!)

From: "Michael Wenk" (mikewenk@attbi.com)
To: vox-tech@lists.lugod.org
Subject: Re: [vox-tech] vim question
Date: Tue, 12 Nov 2002 22:36:00 -0800

If you're su'd and execute any X app, it will give that error, because root doesn't have permissions for X. I used to see this while running emacs, but then emacs would go into non-windowed mode. If you "xhost +root", then you'll be fine.

Date: Tue, 07 Sep 2004 11:23:31 -0700
From: Jeffrey Siegal (jbs@quiotix.com)
To: svlug@lists.svlug.org
Subject: Re: [svlug] couldn't connect to display ":0.0"

Another solution is to have pam_xauth configured on your system. Then it just works.

[RM comments: Despite what Peter Cordes wrote (3rd message up) about xhost being host-based access control only, the xhost manpage makes clear that the name following the "+" can be either the host or the user to be added to the list allowed to connect to the X server. On reflection, then, Michael's suggestion seems the most elegant, easiest, least-security-risky, and best-performing method. However, I often fall back on "ssh -X root@localhost" as an alternative, mostly because it generalises so perfectly to cross-host access without the need to stop and think: The "overhead" objection is entirely bogus on post-486 machines, in my experience.]

From: Yves-Alexis Perez (corsac@debian.org)
To: debian-security@lists.debian.org
Date: Sat, 09 Feb 2008 22:05:34 +0100
Subject: setuid binary in ktsuss

I'm about to upload ktsuss to debian, wich is a graphical wrapper around su (much like gksu but without any gnome dependency). One point puzzles me, the ktsuss binary is setuid root (so it can read the root password). gksu doesn't do this (it calls su, I guess).

I don't really want to upload a setuid binary if it's not safe, but the code looks good (and is really tiny). Could some people on this list take some time and check the code?

dsc can be found at:
http://molly.corsac.net/~corsac/debian/ktsuss_1.3-1.dsc