This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1274451 - sudo with graphical apps doesn't work on wayland
sudo with graphical apps doesn't work on wayland
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: wayland (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs
: 1265707 1266771 1266792 1274634 1370324 1374530 1379148 1384674 1385556 1392261 1398819 (view as bug list)
Depends On:
Blocks: WaylandRelated 1284222
  Show dependency treegraph
 
Reported: 2015-10-22 14:27 EDT by John Dulaney
Modified: 2017-10-09 21:03 EDT (History)
67 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1500124 (view as bug list)
Environment:
Last Closed: 2016-11-28 15:58:23 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Dulaney 2015-10-22 14:27:11 EDT
Description of problem:

When on wayland, both in the tiling compositor orbment as well as Fedora's packaged weston, virt-manager fails to start with the following output:

jdulaney@gefjon:~$ sudo virt-manager
[sudo] password for jdulaney: 
/usr/share/virt-manager/virt-manager:31: PyGIWarning: LibvirtGLib was imported without specifying a version first. Use gi.require_version('LibvirtGLib', '1.0') before import to ensure that the right version gets loaded.
  from gi.repository import LibvirtGLib
/usr/share/virt-manager/virtinst/osdict.py:26: PyGIWarning: Libosinfo was imported without specifying a version first. Use gi.require_version('Libosinfo', '1.0') before import to ensure that the right version gets loaded.
  from gi.repository import Libosinfo as libosinfo
jdulaney@gefjon:~$ No protocol specified
Unable to init server: Could not connect: Connection refused

(virt-manager:30231): Gtk-CRITICAL **: gtk_settings_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed


Version-Release number of selected component (if applicable):

1.2.1-3.fc23

How reproducible:

Always, on at least two Wayland compositors

Steps to Reproduce:
1.  Launch weston
2.  Open terminal
3.  Type sudo virt-manager

Actual results:
Failure

Expected results:
Profit
Comment 1 Cole Robinson 2015-10-27 15:29:40 EDT
It's related to sudo, and doesn't seem virt-manager specific since 'sudo gedit' fails as well
Comment 2 Olivier Fourdan 2015-10-30 05:38:31 EDT
Unlike Xorg being started from gdm, XWayland as started by the Wayland compositor(s) doesn't specify/use an Xauth file, I suspect this might be the problem here.
Comment 3 Olivier Fourdan 2015-10-30 05:43:14 EDT
And this is on purpose obviously, I should have mentioned:

http://cgit.freedesktop.org/xorg/xserver/commit/?id=c4534a3
http://cgit.freedesktop.org/xorg/xserver/commit/?id=4b4b908
http://cgit.freedesktop.org/xorg/xserver/commit/?id=76636ac

So the fix should be to fix the Wayland compositors (namely Weston and mutter/gnome-shell) to use an Xauth file.
Comment 4 Ray Strode [halfline] 2015-10-30 09:11:31 EDT
Right, I guess the question is should UI applications under wayland be allowed to run as root?  It's something we've always really discouraged with X11 apps from one side of our mouth, and but then allowed it with sudo and even ingrained it in early infrastructure with consolehelper.  And, indeed, the risks of doing so are somewhat smaller with wayland because of its more secure architecture

Still, clearly using something like polkit is the "right" way to go.  I think virt-manager even already has polkit integration.  The topic of gedit came up a the columbus day gnome boston summit.  There's a branch to gvfs here to fix that case:

https://git.gnome.org/browse/gvfs/commit/?h=wip/cosimoc/admin&id=1188b586cc3842cc67ee16f2a815540b57dddc7e

Adding an xauth file and letting XAUTHORITY get passed into virt-manager or gedit or whatever would allow them to run with using the X11 backend, but not the wayland backend.  We'd need to fix the compositors (or maybe libwayland? not sure) to allow root connections to get the the wayland backends to work.

I think if we change the compositor (and/or libwayland) to allow root, then changing the compositor to pass an xauth file at the same time probably makes sense (or change the compositor to add a ServerInterpreted root localuser xhost entry).  But xwayland access and wayland access should be as consistent as possible I think, so if we don't allow the wayland connection we shouldn't allow the xwayland connection either, imo.
Comment 5 Ray Strode [halfline] 2015-10-30 09:19:50 EDT
just to clarify comment 4 a little for people less familiar with gtk+...

It supports multiple "backends". One of those backends targets plain old X servers.  One of those backends targets wayland.  gtk+ will try the wayland backend first and if it fails fall back to the X backend.  Wayland compositors provided a compatibility X server called Xwayland that X applications can use to run on wayland. gtk+'s X backend works fine with Xwayland.  So gtk+ applications (like virt-manager and gedit) can run natively using their wayland backend, or via their X backend and the Xwayland compatibility server.  When the compositor starts Xwayland, it can optionally pass an xauth file to it using the "-auth" command line.  If we fixed weston/gnome-shell/etc to start passing -auth then sudo virt-manager and sudo gedit would start working as per comment 2 because even though the wayland backends would fail, the X backends would start working.

My point in comment 4 was both ways of getting access to the display server should have the same access restrictions.  Either allow root in both or deny root in both.
Comment 6 John Dulaney 2015-10-30 11:31:38 EDT
Policy decisions aside, if the decision to go with letting gui applications have root access is made, then I think that the fix should be made in libwayland itself, and not left up to the individual compositors.  It seems that this would be something you would want to have across the board, no matter if you're running Gnome, Weston, or (like I am), a tiling compositor that isn't in Fedora (yet).
Comment 7 Kamil Páral 2015-11-25 04:35:04 EST
*** Bug 1266771 has been marked as a duplicate of this bug. ***
Comment 8 Kamil Páral 2015-11-26 13:14:29 EST
*** Bug 1266792 has been marked as a duplicate of this bug. ***
Comment 9 Kamil Páral 2015-12-08 06:18:13 EST
*** Bug 1274634 has been marked as a duplicate of this bug. ***
Comment 10 Adam Williamson 2016-02-27 15:35:34 EST
I'm gonna nominate this as an Alpha blocker on the basis that I believe it'll stop us running the installer from Workstation live sessions as soon as we actually get Workstation live sessions running on Wayland (the bug for getting that to happen is #1305003). The live installer runs via consolehelper.
Comment 11 Petr Schindler 2016-02-29 13:44:25 EST
Discussed at 2016-02-29 blocker review meeting: [1]. 

We decided to drop blocker nomination on this bug: we believe it makes most sense here to file a new bug for the specific "anaconda on Workstation live" case, if it is indeed broken. that new bug is accepted as a blocker in principle

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2016-02-29/f24-blocker-review.2016-02-29-17.00.html
Comment 12 Vít Ondruch 2016-03-01 06:46:54 EST
Sorry, but although Anaconda was mentioned here explicitly, I really like to use Gvim/Gedit/other_GUI_editor to edit my configuration files. And something like "sudo -e" is hardly equivalent.
Comment 13 Adam Williamson 2016-03-01 10:58:37 EST
yes, that's why we split the anaconda case off: because that's the one we really need to fix, but fixing it may not involve fixing all the other cases.
Comment 14 John Dulaney 2016-03-01 12:28:58 EST
It seems to me that this is a policy decision that needs to be made.  I'm going to ping the Desktop list.
Comment 15 Vít Ondruch 2016-05-06 04:36:25 EDT
Was this implemented? Testing this on Rawhide, it seems I can now use "sudo gvim /etc/someconfigfile.cfg" just fine!!
Comment 16 Vít Ondruch 2016-05-06 04:45:18 EDT
(In reply to Vít Ondruch from comment #15)
> Was this implemented? Testing this on Rawhide, it seems I can now use "sudo
> gvim /etc/someconfigfile.cfg" just fine!!

Ah, I was wrong ... I was running X session for some reason, sorry for the noise :(
Comment 18 Mukundan Ragavan 2016-08-20 16:27:50 EDT
*** Bug 1367745 has been marked as a duplicate of this bug. ***
Comment 19 John Dulaney 2016-08-22 12:26:31 EDT
Switching to rawhide as this is still a thing.
Comment 20 John Reiser 2016-08-26 17:06:56 EDT
*** Bug 1370324 has been marked as a duplicate of this bug. ***
Comment 21 Matthias Clasen 2016-08-31 18:48:25 EDT
*** Bug 1265707 has been marked as a duplicate of this bug. ***
Comment 22 Mukundan Ragavan 2016-09-08 20:48:54 EDT
*** Bug 1374530 has been marked as a duplicate of this bug. ***
Comment 23 Mukundan Ragavan 2016-09-28 21:51:32 EDT
*** Bug 1379148 has been marked as a duplicate of this bug. ***
Comment 24 Nils Philippsen 2016-10-14 08:04:01 EDT
*** Bug 1384674 has been marked as a duplicate of this bug. ***
Comment 25 Mukundan Ragavan 2016-11-01 21:11:14 EDT
*** Bug 1385556 has been marked as a duplicate of this bug. ***
Comment 26 Mukundan Ragavan 2016-11-07 18:38:01 EST
*** Bug 1392261 has been marked as a duplicate of this bug. ***
Comment 27 Ray Strode [halfline] 2016-11-14 09:45:06 EST
just wanted to follow up about the gvfs work mentioned in comment 4.  The bulk of the gvfs stuff landed a while ago, so users can do, e.g.,

gedit admin:///etc/shadow

or whatever.  Also, there's work in getting that integrated in nautilus going on here:

https://bugzilla.gnome.org/show_bug.cgi?id=773937
Comment 28 Vít Ondruch 2016-11-14 10:23:48 EST
(In reply to Ray Strode [halfline] from comment #27)
But how does it help GVim for example?
Comment 29 Ray Strode [halfline] 2016-11-14 15:12:11 EST
the solution outlined in comment 4 doesn't help with gvim or non-gvfs using applications. As an aside, if you're stuck in an unprivileged gvim and need to save, this can help:

:w !pkexec tee %

But i realize that's more a workaround than a solution.
Comment 30 Kamil Páral 2016-11-15 04:40:17 EST
(In reply to Ray Strode [halfline] from comment #29)
> :w !pkexec tee %
> 
> But i realize that's more a workaround than a solution.

Also doesn't help for 'sudo rpmconf -a -f meld' :-)
Comment 31 Mukundan Ragavan 2016-11-21 21:31:43 EST
*** Bug 1397103 has been marked as a duplicate of this bug. ***
Comment 32 Mukundan Ragavan 2016-11-26 08:30:17 EST
*** Bug 1398819 has been marked as a duplicate of this bug. ***
Comment 33 Michael Catanzaro 2016-11-28 15:58:23 EST
OK, to avoid the potential for misunderstood expectations: there are currently no plans to support running graphical apps with sudo under Wayland, and it seems quite unlikely that this will change anytime soon, so I'm going to close this as WONTFIX. The admin:// protocol mentioned by Ray is the way forward for applications that use gvfs to edit root-owned files. Other applications need to use polkit to move privileged operations out of process. This should really have happened many years ago, as polkit is no longer some new or mysterious technology.
Comment 34 Michael Catanzaro 2016-11-28 16:01:17 EST
For more details, please refer to Adam's CommonBugs link two comments up; the situation (including some workarounds) is explained nicely there.
Comment 35 Samuel Sieb 2016-11-28 17:47:32 EST
That link is not accessible at all, so I'll copy it here.  It's truncated in the view at the top and it's not clickable.

https://fedoraproject.org/wiki/Common_F25_bugs#wayland-root-apps
Comment 36 Leslie Satenstein 2016-11-28 19:11:43 EST
Given Wayland's weakness of not being able to support graphical applications is xorg going to be supported until Wayland can support graphical Apps? By having a Wayland compatible virtual terminal, one should be able to do so. If Wayland is not architected to be universal, when can we expect a newer generation software that is able to do so.

Given a multidisk disk system with a virtual terminal,  has a requirement to use gparted from the terminal as   sudo gparted /dev/sdb /dev/sde  (two out of the 6 disks on this system.  

Gparted has centralized information, is visually accurate and appealing, and integrates the UUID, label and partition names.  It is one reason while there is a need to have a graphical interface from the virtual terminal.

When will GUI app allow one to present a command line list?  That ability/facility would solve the reason for the posting of this bug report.
Comment 37 Adam Williamson 2016-11-28 19:24:01 EST
This is not a 'weakness' of Wayland, it's a weakness of gparted (and other graphical applications that try to run as root). gparted should not run its UI as root. It should run its UI as a regular user and use PolicyKit or something else similar to gain elevated privileges only when necessary to query or modify devices.

Many graphical applications have already been written along these lines. Doing it is not rocket science.
Comment 38 Leslie Satenstein 2016-11-28 20:09:36 EST
Hi Adam

I understand your post 37 reply.

I keep a GUI screen open alongside a Gnome terminal. I above (#36) explained how I use gparted often,  but there are other GUI programs that call some programs as a back-end. sudo gparted accepts command line arguments which facilitates what I do. 

With Gparted, I do not always want the full scan of my disks. I want to check out a disk or two from my six. It is important for me to use the easiest tool to get/set a disk's partition information.

When programming, I also keep a GUI "qt-creator" open in one half the screen, and a terminal mode open in the other to do a fast compile and test. I often cut/paste between terminal mode and qt-creator.  

For this bug report and my work method, I cany use Wayland. I can think of one or two creative solutions to a gui interface that integrates a terminal line as a workaround. Now to see if that concept can be generalized.
Comment 39 joerg.lechner 2016-11-29 00:38:42 EST
If it's of interest:
tried to start gparted from Gnome menue (F25 workstation) as user, didn't work. In F24 the root pw was requested, then it did. Tried to start gparted from an xterm with su and pw, didn't work, see log. Logged in as root, xterm, start gparted, gparted started -> ok.
Here the log xterm as user, su and pw:

[joerg@linux ~]$ su
Passwort:
[root@linux joerg]# gparted
Created symlink /run/systemd/system/-.mount → /dev/null.
Created symlink /run/systemd/system/boot-efi.mount → /dev/null.
Created symlink /run/systemd/system/boot.mount → /dev/null.
Created symlink /run/systemd/system/home.mount → /dev/null.
Created symlink /run/systemd/system/proc-fs-nfsd.mount → /dev/null.
Created symlink /run/systemd/system/run-user-0.mount → /dev/null.
Created symlink /run/systemd/system/run-user-1000.mount → /dev/null.
Created symlink /run/systemd/system/run-user-42.mount → /dev/null.
Created symlink /run/systemd/system/tmp.mount → /dev/null.
Created symlink /run/systemd/system/var-lib-machines.mount → /dev/null.
Created symlink /run/systemd/system/var-lib-nfs-rpc_pipefs.mount → /dev/null.
No protocol specified

(gpartedbin:4086): Gtk-WARNING **: cannot open display: :0
Removed /run/systemd/system/-.mount.
Removed /run/systemd/system/boot-efi.mount.
Removed /run/systemd/system/boot.mount.
Removed /run/systemd/system/home.mount.
Removed /run/systemd/system/proc-fs-nfsd.mount.
Removed /run/systemd/system/run-user-0.mount.
Removed /run/systemd/system/run-user-1000.mount.
Removed /run/systemd/system/run-user-42.mount.
Removed /run/systemd/system/tmp.mount.
Removed /run/systemd/system/var-lib-machines.mount.
Removed /run/systemd/system/var-lib-nfs-rpc_pipefs.mount.
[root@linux joerg]#
Comment 40 Adam Williamson 2016-11-29 01:32:30 EST
joerg: we don't need logs or anything like that. there is no debugging to be done here. we know exactly what is happening, it's a perfectly well-understood situation. gparted needs to be rewritten for a Wayland world, there's really not much more to it than that.
Comment 41 Kamil Páral 2016-11-29 06:36:41 EST
(In reply to Michael Catanzaro from comment #33)
> The admin:// protocol mentioned by Ray
> is the way forward for applications that use gvfs to edit root-owned files.
> Other applications need to use polkit to move privileged operations out of
> process.

I'm afraid none of those are usable for a script which launches a GUI application frequently, like my use case in comment 30. Even if meld supported polkit, I wouldn't want to enter password for each opened file. Also the script which launches meld needs to run under root, for obvious reasons.
Comment 42 Michael Catanzaro 2016-11-29 08:28:28 EST
(In reply to Kamil Páral from comment #41) 
> I'm afraid none of those are usable for a script which launches a GUI
> application frequently, like my use case in comment 30. Even if meld
> supported polkit, I wouldn't want to enter password for each opened file.

The admin:// protocol handler should just use auth-admin-keep, it's basically "sudo mode" where you only have to enter your password once every five minutes or so.

> Also the script which launches meld needs to run under root, for obvious
> reasons.

I guess you'll need a meld wrapper script that does "su kparal -c meld". It won't work for all apps -- the app menu in meld is broken because it can't find the session bus, not sure why -- but it seems to mostly work. Maybe someone else can improve on this.
Comment 43 bober 2016-11-29 09:22:51 EST
I found the solution.
The essence of the problem is that in a call to the socket is checked euid, egid process that is connected

We cover euid, egid by proxy.

Example:
socat UNIX-LISTEN:/tmp/.X11-unix/X1 UNIX-CONNECT:/tmp/.X11-unix/X0 & sudo DISPLAY=:1 gparted
Comment 44 Florian Weimer 2016-11-29 09:45:17 EST
(In reply to bober from comment #43)
> I found the solution.
> The essence of the problem is that in a call to the socket is checked euid,
> egid process that is connected
> 
> We cover euid, egid by proxy.
> 
> Example:
> socat UNIX-LISTEN:/tmp/.X11-unix/X1 UNIX-CONNECT:/tmp/.X11-unix/X0 & sudo
> DISPLAY=:1 gparted

This looks like it introduces a local security hole, but it's of course what people will do to get the job done.  There is also an xhost-based approach, which might not open up the display to all local users.

We will eventually need a solution downstream for installing software which comes with graphical installers, too.
Comment 45 Michael Catanzaro 2016-11-29 09:52:28 EST
(In reply to Florian Weimer from comment #44)
> We will eventually need a solution downstream for installing software which
> comes with graphical installers, too.

Maybe for RHEL, but please not for Fedora. We *really* do not want to allow such things. Either use polkit to make your installer work, or learn to distribute your software properly as graphical installers have not been acceptable on Linux for longer than I can remember.
Comment 46 Michael Catanzaro 2016-11-29 09:53:33 EST
I think an appropriate solution to that problem in Fedora would be to set up a custom Flatpak bundle for the software in situations where upstream is dumb and uncooperative.
Comment 47 Christian Stadelmann 2016-11-29 11:17:03 EST
(In reply to Leslie Satenstein from comment #38)
(In reply to Leslie Satenstein from comment #36)

Most GUI toolkits including Gtk+ are not designed with being run as root in mind. Running GUI apps as root is dangerous in multiple ways. This is why GNOME people decided to dump this broken feature.

(In reply to Michael Catanzaro from comment #46)
> I think an appropriate solution to that problem in Fedora would be to set up
> a custom Flatpak bundle for the software in situations where upstream is
> dumb and uncooperative.

Please watch your language. No need in insulting people just because they have a different opinion based on a different perspective.
Comment 48 Florian Weimer 2016-11-29 11:43:57 EST
(In reply to Christian Stadelmann from comment #47)
> Most GUI toolkits including Gtk+ are not designed with being run as root in
> mind. Running GUI apps as root is dangerous in multiple ways. This is why
> GNOME people decided to dump this broken feature.

What does this mean for the future of anaconda?
Comment 49 Christian Stadelmann 2016-11-29 12:22:50 EST
(In reply to Florian Weimer from comment #48)
> (In reply to Christian Stadelmann from comment #47)
> > Most GUI toolkits including Gtk+ are not designed with being run as root in
> > mind. Running GUI apps as root is dangerous in multiple ways. This is why
> > GNOME people decided to dump this broken feature.
> 
> What does this mean for the future of anaconda?

Anaconda's GUI probably needs to live in a separate process. I've found a more specific bug and filed it in bug report #1399772.
Comment 50 Kamil Páral 2016-11-30 04:35:52 EST
(In reply to Michael Catanzaro from comment #42)
> I guess you'll need a meld wrapper script that does "su kparal -c meld".

Unfortunately that doesn't help either. If I run it as kparal, I can display the app but I can't save the changes (because those are root-owned files). If I run it as root, I can't display the app.
Comment 51 Michael Catanzaro 2016-11-30 09:38:15 EST
(In reply to Christian Stadelmann from comment #47) 
> Please watch your language. No need in insulting people just because they
> have a different opinion based on a different perspective.

Sorry.

(In reply to Florian Weimer from comment #48)
> What does this mean for the future of anaconda?

Er, I don't know... I guess nothing, because it works now, right? I don't know why it still works, but if it works now it should continue to work in the future. What is it doing now, running under X11?

(In reply to Kamil Páral from comment #50)
> Unfortunately that doesn't help either. If I run it as kparal, I can display
> the app but I can't save the changes (because those are root-owned files).
> If I run it as root, I can't display the app.

In the case of meld I think it should be able to use admin://, since it's using GtkFileChooser to open files and that implies that gvfs support should be built-in... right? admin:// is currently broken in F25 unfortunately, but it should be fixed soon I hope.
Comment 52 Christian Stadelmann 2016-11-30 09:42:12 EST
(In reply to Michael Catanzaro from comment #51)
> (In reply to Christian Stadelmann from comment #47) 
> > Please watch your language. No need in insulting people just because they
> > have a different opinion based on a different perspective.
> 
> Sorry.
> 
> (In reply to Florian Weimer from comment #48)
> > What does this mean for the future of anaconda?
> 
> Er, I don't know... I guess nothing, because it works now, right? I don't
> know why it still works, but if it works now it should continue to work in
> the future. What is it doing now, running under X11?

Yes, runs under X11.

> (In reply to Kamil Páral from comment #50)
> > Unfortunately that doesn't help either. If I run it as kparal, I can display
> > the app but I can't save the changes (because those are root-owned files).
> > If I run it as root, I can't display the app.
> 
> In the case of meld I think it should be able to use admin://, since it's
> using GtkFileChooser to open files and that implies that gvfs support should
> be built-in... right? admin:// is currently broken in F25 unfortunately, but
> it should be fixed soon I hope.

No, meld doesn't support gvfs. See also: https://bugzilla.gnome.org/show_bug.cgi?id=317875
Comment 53 Dominik Gronkiewicz 2016-12-05 19:20:23 EST
(In reply to Michael Catanzaro from comment #45)
> (In reply to Florian Weimer from comment #44)
> > We will eventually need a solution downstream for installing software which
> > comes with graphical installers, too.
> 
> Maybe for RHEL, but please not for Fedora. We *really* do not want to allow
> such things. Either use polkit to make your installer work, or learn to
> distribute your software properly as graphical installers have not been
> acceptable on Linux for longer than I can remember.

Just my three cents from end-user point of view.

Graphical installers are used for many enterprise applications (such as Intel compiler suite). I guess they know how to distribute their software properly. Making people unable to install the tools they need only because of aesthetic reasons (which are your subjective opinions, not backed by any facts) will end up in Fedora losing its significance even further.
Comment 54 Adam Williamson 2016-12-05 19:50:10 EST
There's no reason at all you can't write a graphical installer that works with policykit. This is, after all, precisely what GNOME Software is. It makes the software more secure, more flexible, and nicer for the user to use.
Comment 55 Dominik Gronkiewicz 2016-12-06 07:06:57 EST
(In reply to Adam Williamson from comment #54)
> There's no reason at all you can't write a graphical installer that works
> with policykit. This is, after all, precisely what GNOME Software is. It
> makes the software more secure, more flexible, and nicer for the user to use.

Please don't get me wrong -- I personally hate graphical installers and distribute my own software only by "traditional" way (source / source rpms). However, sometimes you are forced to use a piece of proprietary software that has a graphical installer. Since Fedora is targeted to professionals and developers, I believe that would be a bad decision for most of its user base :(
Comment 56 Kevin Kofler 2016-12-06 17:24:36 EST
KDE Partition Manager and Calamares also need to run as root.
Comment 57 Muthu Kumar 2016-12-14 21:01:39 EST
AMPPS (only lamp stack with multiple php versions with nice gui) needs to run as root.
The solution is simple. Those who are web developers who needs older php versions, please use xorg and avoid wayland.
Comment 58 Adam Williamson 2016-12-14 21:06:35 EST
"AMPPS (only lamp stack with multiple php versions with nice gui) needs to run as root."

This may be the most horrifying sentence I've ever read in a bug report.
Comment 59 Muthu Kumar 2016-12-14 23:17:22 EST
(In reply to Adam Williamson from comment #58)
> "AMPPS (only lamp stack with multiple php versions with nice gui) needs to
> run as root."
> 
> This may be the most horrifying sentence I've ever read in a bug report.

I am really sorry.I don't know better Lamp stack other than Ampps. I don't know about XAMP needs to run as root or not. But if you know Better Lamp stack (Multiple PHP) to continue use wayland , you can freely recommend it to me.
Comment 60 Adam Williamson 2016-12-15 01:09:43 EST
Sorry, I was being a bit flippant there. It's just the idea of anything that runs some sort of graphical wrapper around multiple versions of PHP as root sounds like a really, really awful idea to me.

If you really need that thing, though, yes, you will have to use X for now.
Comment 61 aairey 2016-12-15 04:07:42 EST
Some VPN software with GTK gui (fortisslvpn) also needs to run with sudo permissions.
Comment 62 Adam Williamson 2016-12-15 09:58:52 EST
We don't really need a list of GUI processes that want to run as root. We are aware such things exist. The point is that they're a bad idea and always have been, and the switch from X to Wayland is an excellent point at which to say "this is the point where we're not going to enable this bad idea any more, and tell people to make better, more robust, more secure software instead". If we never do that, we continue to have bad, insecure software forever.

If you really need something that has to run as a GUI root process right now, and none of the workarounds discussed earlier in the bug works for you, by all means, switch back to X for now. There's a reason we keep X as a prominent option in F25.
Comment 63 Biji 2016-12-21 03:01:53 EST
Workaround:
Typing "xhost +" as current login user, allow those apps to run
Comment 64 axel simon 2016-12-21 10:48:19 EST
The workaround in #63, xhost +, is a bit brutal: it allows any and all users to access our local user's graphical session.

For a workaround a little less bad, you can use the following (which is essentially what Ray suggested in #4, “change the compositor to add a ServerInterpreted root localuser xhost entry”), which will allow only root to access your local user's X session:
xhost si:localuser:root

then use "xhost -si:localuser:root" (notice the "-") to remove the access, once you've done what you had to do as root. Again, not a solution but a temporary workaround, the gist of the issue is that some apps will need to be rewritten with Wayland in mind, as explained by Adam in #40.
Comment 65 Muthu Kumar 2016-12-22 11:07:04 EST
Thank you axel simon. your solution is enabled me to use ampps on wayland with those 4 Commands. :)

1) As normal user run cmd "xhost + localhost"
2) login to root and run cmd "export QT_X11_NO_MITSHM=1"
3) cd /usr/local/ampps
4) ./Ampps
Comment 66 axel simon 2016-12-22 12:08:20 EST
Good to hear Muthu. However, I'd keep in mind the different comments Adam made, running PHP as root does sound like a dangerous idea.

Also, don't forget to remove any temporary rights you grant root once you don't need them anymore.
Comment 67 DuvJones 2017-01-31 15:00:58 EST
Came across this bug with grub-customizer, the program is fine under X11 but won't even attempt to boot in Wayland. Since this is a matter of the way that wayland is designed, I don't think that there will be much of an answer to this but I felt that it should be mentioned aside from voicing my bigger concern.

(In reply to Adam Williamson from comment #62)
> The point is that they're a bad idea and always have been, and the switch from X to Wayland is an excellent point at which to say "this is the point where we're not going to enable this bad idea any more, and tell people to make better, more robust, more secure software instead". If we never do that, we continue to have bad, insecure software forever.

Honestly, I get that. I don't see much of the point of give an application with a gui root access if it can be helped. Such appilcation are can be way too broad to allow that to happpen. My only problem with this is one question: Are we thinking of the day when X11, as a fall-back, isn't the option anymore?

We have, both in Fedora and outside of it, have promoted Wayland as the replacement to X11. One that, I will admit, the community has been in desperate need of, but if that is the case.... are we thinking of a future were X11 isn't around? Do we have a plan for uses cases (limited in scope of course) like this one?
Because I think that the current thinking around wayland is that it is a drop-in replacement for X11, which be both know that isn't the case. So it's really a question of how we do this differently without braking the security model to do it? Any ideas?
Comment 68 Nate Graham 2017-01-31 15:23:13 EST
The solution is for the owners of problematic programs to fix them, no? Or for other interested parties to submit patches.
Comment 69 aairey 2017-02-01 11:14:06 EST
Yes, and to be precise a fix could be (for example) an "Unlock" button like GNOME uses on the user Settings for example.

IMHO this is a winning combination of usability and security.
Comment 70 Nathanael Schilling 2017-05-08 08:30:20 EDT
>If we never do that, we continue to have bad, insecure software forever.

If the decision is made not to allow GUI apps to run in root for security reasons, then that change alone is bad software already and quite frankly I'm surprised such a ridiculous idea is actually taken seriously. Unix itself is a whole mess of hacks that disregards good design (see e.g. "The Unix-Haters Handbook") - but this hasn't stopped its widespread adoption. One reason is that Unix puts the responsibility for not shooting onesself in the foot on the side of the programmer, making it easy to develop software quickly (even if said software is bad). In the same way, it should be easy to use Fedora - even if it becomes easy to shoot onesself in the foot by doing so. The reason I switched to fedora was that my previous distro (ubuntu) was making too many decisions for the user that were hard/impossible to circumvent. As can be seen by the large number of comments, there are plenty of people who want to run GUI apps as root. Whether this is to use proprietary installers (which exist), use old software (which exists) or are too lazy to learn policykit (I don't blame them for it, if I were to program a GUI application that runs as root for my own use, I wouldn't bother learning policykit either), it is clear that being able to run GUI apps as root is important. 

You cannot protect the user against himself, nor is it your job to do so. What people like myself will now do is search for a workaround (such as running socat UNIX-LISTEN:/tmp/.X11-unix/X1 UNIX-CONNECT:/tmp/.X11-unix/X0 & sudo DISPLAY=:1 gparted ) and not care about the question whether or not that introduces security vulnerabilities or not. Once I cannot find a hack/workaround to run GUI apps as root I will switch distros to something that can.
Comment 71 Christian Stadelmann 2017-05-08 08:59:41 EDT
(In reply to Nathanael Schilling from comment #70)
> >If we never do that, we continue to have bad, insecure software forever.
> 
> If the decision is made not to allow GUI apps to run in root for security reasons, then that change alone is bad software already and quite frankly I'm surprised such a ridiculous idea is actually taken seriously.

> Unix itself is a whole mess of hacks that disregards good design (see e.g. "The Unix-Haters Handbook") - but this hasn't stopped its widespread adoption.

When Unix and Xorg were designed, both IT security and malware weren't even a thing. And that it "worked for the last few decades" does not mean to repeat the same mistakes again and hard-code them for the next few decades.

> One reason is that Unix puts the responsibility for not shooting onesself in the foot on the side of the programmer, making it easy to develop software quickly (even if said software is bad). In the same way, it should be easy to use Fedora - even if it becomes easy to shoot onesself in the foot by doing so.

There is no need to write software to run as root. With polkit and other technology, there are many ways to run your GUI with lower privileges than the code which actually modifies your system or does whatever it requires privileges for.

> The reason I switched to fedora was that my previous distro (ubuntu) was making too many decisions for the user that were hard/impossible to circumvent. As can be seen by the large number of comments, there are plenty of people who want to run GUI apps as root.

I repeat, this is not needed any more. gnome-disks or gnome-software, for example, use polkit to make sure they can modify the disks or installed software and still run as user. GEdit now (on Gnome 3.24) has a mode where it can transparently edit files with root permissions without running as root. Afaik, nautilus has a similar mode to open folders which can only be read by root through a similar mechanism. This is the way to go.

> Whether this is to use proprietary installers (which exist), use old software (which exists) or are too lazy to learn policykit (I don't blame them for it, if I were to program a GUI application that runs as root for my own use, I wouldn't bother learning policykit either), it is clear that being able to run GUI apps as root is important.

Compatibility for the old stuff will not go away soon. You can still do that. No need to panic.

> You cannot protect the user against himself, nor is it your job to do so.

So all the "confirm delete" and similar dialogs are plain bullshit? Or the "do you want to close this document without saving" dialogs? Or the "do you really want to format this disk and loose all data on it?" dialogs? I do think it is the programmers job to protect the user from doing bad stuff by accident or by ignorance, to some extent. If you don't agree yet, would you disable all the security features and patches in your browser so that anybody can hack it within seconds? I don't think so. It is the task of any programmer to protect the user.

One example: GParted had a major security issue¹ which resulted in a browser being run as root. Graphical toolkits were not designed (and are not being designed) for running as root.

¹ See https://bugzilla.gnome.org/show_bug.cgi?id=758131#c2
Comment 72 Nathanael Schilling 2017-05-08 09:49:03 EDT
> When Unix and Xorg were designed, both IT security and malware weren't even a thing. 

How much Unix and Xorg were actually designed is a matter of debate :). But even then it was clear that there were systems that were better in a lot of ways (e.g. LISP-Machines) but people still ended up using Unix. My point had nothing to do with "it worked in the past few decades", reread it again and hopefully it will make more sense. I'm saying that people/programmers will use whatever system makes it easy/possible to do things. 

> I repeat, this is not needed any more.

I don't care whether or not you agree that it is needed, there are clearly people who would like to do this (for whatever reason).

>Compatibility for the old stuff will not go away soon. You can still do that. No need to panic.

The only reason that I'm even reading this thread is because compatibility for the old stuff is going away. I was unable to run gparted in root mode without resorting to a hack (and I don't know when said hack will go away)

>So all the "confirm delete" and similar dialogs are plain bullshit? Or the "do you want to close this document without saving" dialogs? Or the "do you really want to format this disk and loose all data on it?" dialogs?

If the system won't let me bypass dialogs like that then yes, they would be bullshit. But here we aren't even talking about a dialog that can easily be gotten around. We have plenty of those already. What we're talking about is making it impossible to do a certain thing on a system.
Comment 73 q2dg 2017-09-04 07:15:20 EDT
I can't run Tuna grafically (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/2/html/Tuna_User_Guide/chap-Tuna_User_Guide-Using_the_Graphical_User_Interface.html) on Fedora 26 because of this. Should I wait packagers to include a polkit file inside the package? It's a shame.

Note You need to log in before you can comment on or make changes to this bug.