After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 772875 - [wayland] can't run application as root using sudo
[wayland] can't run application as root using sudo
Status: RESOLVED NOTABUG
Product: gtk+
Classification: Platform
Component: Backend: Wayland
3.21.x
Other Linux
: Normal major
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-10-13 16:02 UTC by Mohammed Sadiq
Modified: 2018-01-06 12:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Mohammed Sadiq 2016-10-13 16:02:18 UTC
No application can be run as root.

Eg: 'sudo gedit' Gives the following output:

on Debian testing:
Invalid MIT-MAGIC-COOKIE-1 keyUnable to init server: Could not connect: Connection refused

(gedit:3460): Gtk-WARNING **: cannot open display: :0

Version details:
gnome-shell: 3.22.0
wayland-protocols: 1.7
libwayland-bin: 1.11

on Fedora 24:
No protocol specified
Unable to init server: Could not connect: Connection refused

(gedit:2349): Gtk-WARNING **: cannot open display: :0

Version details:
gnome-shell: 3.20
wayland-protocols: 1.4
libwayland-server: 1.10

Please reassign to the right module if not related to gtk+ (or forward to wayland if it's an upstream bug)

Thanks.
Comment 1 Matthias Clasen 2016-10-13 16:54:37 UTC
Not a bug, per se. Running graphical applications as root in this way is not the recommended way to go about things.

If you insist,
XDG_RUNTIME_DIR=/run/user/$PID gedit
will work as root
Comment 2 Emmanuele Bassi (:ebassi) 2016-10-13 17:45:41 UTC
To further elaborate: the appropriate way to run gedit with sudo is:

  set EDITOR=gedit
  sudo -e /etc/some/file/owned/by/root

which will run gedit in your session, on a temporary file, and then sudo will swap the temporary file with the target.

If you want to just browse files, GVFS now has an 'admin:' URI scheme which will let you open files via appropriate privilege escalation through polkit.

In short: there is no reason whatsoever to run a GUI application — with its unknown security surface, using various dependencies at build and run time, themselves with unknown security surface — as root.
Comment 3 Mohammed Sadiq 2016-10-13 23:54:54 UTC
Hm.. Lots of newbies will have hard time to move from X11 to wayland then. Yeah, I agree, this will improve security tho.
Comment 4 taijian 2016-10-18 12:50:22 UTC
I am sorry, but I do take issue with the stance that: "There is no reason whatsoever to run a GUI application as root". What you mean to say is that YOU PERSONALLY can not think of an instance where the benefit of doing so will outweigh the downsides, as you perceive them, of doing so. To say that there definitely is no reason, and that there can never BE any reson, to see things differently, is the exact same mindset of engineered arrogance that drove me away from Microsoft Windows. 

Suppose, just for the moment, that I would like to run GParted. That is a GUI application that kinda benefits from being run as root. Of course, there is no NEED, as such, to use this particular application. I could just use parted from the CLI. But, just suppose, that I would rather like to do some things in a GUI. And just suppose, for a moment, that there are other people out there, who, like me, would like to continue to use Linux, but with a functional GUI, that lets us do things we are not allowed to do in Windows, because they are dangerous. 

Linux lets me do stuff like 'sudo rm -rf /*'. Yet I manage. So don't try to patronize everyone by telling them they can't run GUI applications as root 'because it is dangerous'. Unless you WANT to make people use X. Because this is how you make people use X.
Comment 5 Emmanuele Bassi (:ebassi) 2016-10-18 13:28:57 UTC
(In reply to taijian from comment #4)
> I am sorry, but I do take issue with the stance that: "There is no reason
> whatsoever to run a GUI application as root". What you mean to say is that
> YOU PERSONALLY can not think of an instance where the benefit of doing so
> will outweigh the downsides, as you perceive them, of doing so.

Speaking as the developer of a GUI toolkit, and as an application developer, no: there are no *real*, substantiated, technological reasons why anybody should run a GUI application as root. By running GUI applications as an admin user you're literally running millions of lines of code that have not been audited properly to run under elevated privileges; you're also running code that will touch files inside your $HOME and may change their ownership on the file system; connect, via IPC, to even more running code, etc.

You're opening up a massive, gaping security hole — likely because application developers were too lazy to properly do separation between the code that creates and manages the GUI bits, and the code that executes the privileged operations.

> To say that
> there definitely is no reason, and that there can never BE any reson

It's software: *everything* is possible.

It's possible that, at some point down the line, all the code on your OS will be auditable *and* audited, and it's going to be safe to trust every application, library, service, and kernel module, including all the potential interactions between all these components. It's possible, but *incredibly* unlikely.

Additionally, this is not the direction things are going; applications are untrusted by default, because they may come from anywhere and signing them with a GPG key does not make automatically trustworthy; and, as such, GUI applications are getting sandboxed — at various levels: file system, network, display server, etc.

> to see things differently, is the exact same mindset of engineered arrogance
> that drove me away from Microsoft Windows. 

To see things differently from your position is just the result of actually having to write the OS that you're using.

> Suppose, just for the moment, that I would like to run GParted. That is a
> GUI application that kinda benefits from being run as root.

No, it really doesn't.

The GUI part should be running as your user, and it should defer the privileged operations to an auditable, self-contained, *minimal* piece of code that gets executed after doing a privilege escalation, and gets dropped when not needed.

This is how applications that interact with any privileged operation, such as interacting with hardware or with system services, should be written.

> Of course, there
> is no NEED, as such, to use this particular application. I could just use
> parted from the CLI. But, just suppose, that I would rather like to do some
> things in a GUI. And just suppose, for a moment, that there are other people
> out there, who, like me, would like to continue to use Linux, but with a
> functional GUI, that lets us do things we are not allowed to do in Windows,
> because they are dangerous. 

That has nothing to do with Windows.

Modern Windows API and applications use sandboxing, localised privilege escalation, and separation of logic from UI.

Linux applications don't, because they were written for a platform that did not have any of these things, and assumed that the users were capable of just fixing a hosed system. This is not true any more, if it ever was true.

> Linux lets me do stuff like 'sudo rm -rf /*'.

Which is not a GUI application, it's self-contained, does not call random services via IPC, and it's easily auditable.

> Yet I manage. So don't try to
> patronize everyone by telling them they can't run GUI applications as root
> 'because it is dangerous'.

It's not "because it's dangerous"; that's a straw man that you built yourself out of your entitlement and lack of understanding, and are now having fun dismantling. It's also something I did not say.

GUI applications should not run as root because it's *insecure*. Because it's irresponsible towards users and their data. And, lastly, because it's simply not necessary, given the technological context in which applications are written.

> Unless you WANT to make people use X. Because
> this is how you make people use X.

X was written with a security and threat model that is simply irresponsible to use in 2016.
Comment 6 thebunnyrules 2017-12-31 00:31:45 UTC
(In reply to Emmanuele Bassi (:ebassi) from comment #5)

Emmanuele, you made some really good points in your comments. I used to run root GUIs until now but after having read this thread, I've decided to avoid it altogether and installed Midnight Commander and Midnight Commander Editor as command-line alternatives to GUI based file browsing and text editing while in root. 
 

That being said, I don't agree with your stance that there are no legitimate uses for running root privileged GUIs:

- 1) whether you agree with the design principle or not there are GUI apps that con only be run in root:
    - whether it benefits from it or not, gparted needs to be run as root.  that's just the way it was designed. If you run it as user, it will warn you that most of it's features aren't going to work. It's a small GUI, a 15 year old project still under active development and it was meant to be run with admin rights, chances are the code has been fully vetted for admin privilleges and the risk of using as sudo are minimal.
    - synapatic package manager: same thing: designed to be run as root, tells you to run it as root when run as user, 17 years of active dev, small GUI.

I agree with you that ideal design would be for these apps to run as user and escalate privelleges when running root OPs but that's the way they were designed and we should have the ability to run them as root in Wayland without having to resort to opening them with xhost 

bash -c "xhost +SI:localuser:root;pkexec synaptic"

and downgrading our security by running root privileged GUI on a snoop happy X11 server.

- 2) even people who don't want to run a root privileged GUI may want to have the option of running GUIs as another user under Wayland (without having to resort to xhost):
     -I've setup a restricted account on my Ubuntu install that doesn't have reading/access privileges to my home folder, nor does it have access to pkexec, sudo, gksudo, ksudo, the polkit action folder. The account is used to run proprietary software that may or may not be well behaved. It would have been nice to have a wayland equivalent to xhost +SI to run GUI via the restricted account without having to switch users.
Comment 7 thebunnyrules 2017-12-31 00:34:20 UTC
(In reply to Matthias Clasen from comment #1)
> Not a bug, per se. Running graphical applications as root in this way is not
> the recommended way to go about things.
> 
> If you insist,
> XDG_RUNTIME_DIR=/run/user/$PID gedit
> will work as root

Hello Matthias, this doesn't seem to work under Wayland, it gives the following error:


Invalid MIT-MAGIC-COOKIE-1 keyUnable to init server: Could not connect: Connection refused

(gedit:2228): Gtk-WARNING **: cannot open display: :0


I'm guessing that's due to Wayland's security restrictions.
Comment 8 Matthias Clasen 2018-01-05 19:33:07 UTC
no. those warnings indicate that you are using X
Comment 9 thebunnyrules 2018-01-06 12:17:10 UTC
I don't think so, it happened while I was in Wayland. I've tried it on several occasions and it works fine when logged into X.