On 18/06/13 03:10, Bas Wijnen wrote:
Gnome 3 (non-classic) has a different way of handling
applications. When selecting to open an already open application,
the intended behaviour is to focus that window, not to open a new
one. You may not like it, but that is not a bug; it's an
intentional feature.
Right. (FWIW, if you don't like it, I think there's an extension that
makes clicking on applications always behave like new window.)
So the question is whether a terminal and a root terminal are the
same application. Technically they are, intuitively they aren't.
The root terminal .desktop file is provided by gksu, and is
implemented as gksu /usr/bin/x-terminal-emulator; so they are both
gnome-terminal, but run as different users. The app-centric model in
GNOME Shell doesn't really have an answer for that, except stop
running GUI apps as root (see below).
The bug is that it is different: if I read this right, then a root
terminal is not considered the same thing as a terminal (so it can
be opened when a terminal is open), but a terminal is the same
thing as a root terminal (so it cannot be opened normally).
The reason for the difference is that in each situation, one flavour
of terminal is a running application and one is a launcher for an
as-yet unstarted application. GNOME Shell can't tell exactly what the
launcher is going to do.
When you're running a root gnome-terminal and you click on Terminal in
the applications list, GNOME Shell asks: is there a window open that I
have associated with gnome-terminal.desktop via various heuristics?
(Mostly WM_CLASS, but there are others: see the source code to the C
parts of gnome-shell if you're interested.) The answer is yes,
because the root gnome-terminal still has WM_CLASS=gnome-terminal, so
it brings it to the foreground instead of starting a new one.
When you're running a normal gnome-terminal and you click on Root
Terminal in the applications list, GNOME Shell asks: is there a window
open that I have associated with gksu-terminal.desktop? The answer is
no, because windows with WM_CLASS=gksu-terminal don't exist, and it
doesn't know that on this particular system, gksu-terminal ends up
running gnome-terminal. So, it runs gksu, starting a new
gnome-terminal instance (as root).
I would argue that running a GUI application as root is not a great
idea anyway[1][2], and I suspect gnome-terminal and GNOME Shell
upstream developers would consider this to be something they don't
want to support. There has been a general move towards separating
things into an unprivileged GUI frontend that communicates with a
privileged non-GUI daemon, with authorization via PolicyKit (like
GNOME communicating with NetworkManager, BlueZ, Avahi etc.), which I
think is a better model.
In particular, applications under (gk)su (although not sudo or pkexec)
inherit environment variables from the user environment, leading to
failure to do things like connect to D-Bus (because they see the
user's $DBUS_SESSION_BUS_ADDRESS: D-Bus implementations can't
currently connect to a different user's session bus even when running
as root, and if they could, it would potentially be a security flaw,
so they probably shouldn't gain this functionality).
A better implementation of give me a GUI terminal where I can run
root commands might be something like
x-terminal-emulator -e pkexec su --login
or if the can run other X applications from this terminal as root
property is required,
/bin/sh -c 'exec x-terminal-emulator -e pkexec env
DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY su --login'
or we could follow what Ubuntu did: get rid of the Root Terminal
launcher altogether, and instead say open a normal terminal and use
sudo, or sudo -s if you need a root shell.
(The su in those pkexec command-lines is unnecessary for
privilege-escalation - pkexec does that bit - but was the first way I
found to say find and execute root's configured login shell... there
is probably a better way.)
I'm tempted to look into mass-bug-filing for use of gksu, at least
among GNOME applications. If it is really necessary to run a GUI as
root, then pkexec is a better gksu in many ways: it clears the
environment (except for a small whitelist of safe variables), it
defaults to allowing members of the sudo group to escalate privileges
by typing their own password (like sudo), it can be configured to be
passwordless, and if nobody is in the sudo group, it falls back to
asking for the root password (like su does).
S
[1] https://lwn.net/Articles/551658/
The X.Org security team would like to take this opportunity to
remind X client authors that current best practices suggest
separating code that requires privileges from the GUI
[2] http://www.gtk.org/setuid.html
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
