It's related to sudo, and doesn't seem virt-manager specific since 'sudo gedit' fails as well

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.

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.

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.

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.

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).

*** Bug 1266771 has been marked as a duplicate of this bug. ***

*** Bug 1266792 has been marked as a duplicate of this bug. ***

*** Bug 1274634 has been marked as a duplicate of this bug. ***

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.

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

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.

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.

It seems to me that this is a policy decision that needs to be made.  I'm going to ping the Desktop list.

Was this implemented? Testing this on Rawhide, it seems I can now use "sudo gvim /etc/someconfigfile.cfg" just fine!!

(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 :(

*** Bug 1367745 has been marked as a duplicate of this bug. ***

Switching to rawhide as this is still a thing.

*** Bug 1370324 has been marked as a duplicate of this bug. ***

*** Bug 1265707 has been marked as a duplicate of this bug. ***

*** Bug 1374530 has been marked as a duplicate of this bug. ***

*** Bug 1379148 has been marked as a duplicate of this bug. ***

*** Bug 1384674 has been marked as a duplicate of this bug. ***

*** Bug 1385556 has been marked as a duplicate of this bug. ***

*** Bug 1392261 has been marked as a duplicate of this bug. ***

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

(In reply to Ray Strode [halfline] from comment #27)
But how does it help GVim for example?

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.

(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' :-)

*** Bug 1397103 has been marked as a duplicate of this bug. ***

*** Bug 1398819 has been marked as a duplicate of this bug. ***

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.

For more details, please refer to Adam's CommonBugs link two comments up; the situation (including some workarounds) is explained nicely there.

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

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.

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.

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.

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]#

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.

(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.

(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.

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

(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.

(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.

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.

(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.

(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?

(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.

(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.

(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.

(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

(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.

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.

(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 :(

KDE Partition Manager and Calamares also need to run as root.

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.

"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.

(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.

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.

Some VPN software with GTK gui (fortisslvpn) also needs to run with sudo permissions.

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.

Workaround:
Typing "xhost +" as current login user, allow those apps to run

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.

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

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.

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?

The solution is for the owners of problematic programs to fix them, no? Or for other interested parties to submit patches.

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.

>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.

(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

> 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.

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.

I see the real reason of this bug is lack of foresight. Someone just made an desktop API for single user environment and later hypocritically claim that it was done intentionally to force people not to run root gui and bla bla bla. finally in the world of MAC (mandatory access control) OSes like Android. Desktop users are forced to use insecure desktops were all the programs share the same user rights and can interact with each other in any vicious way they want. Good luck with keyloggers shared clipboard access etc etc. You aren't even allowed to run apps from a different user account on your desktop by design. One should at least accept that this is a design flaw and not a feature. But he claim that this was supposedly done to make desktop more secure. What a shame.

try this, either you still consider it is a security features or not.
keep in mind, i'm using gnome v3.26.2 with the wayland (not xorg).

1. Install nemo file manager v3.6.5
2. try out the feature call "open as root"

than pls come back here and tell us, it is a security features or your design flaw?

the solution for the above is, i have to run "xhost si:localuser:root" for making it work.

if it is a design flaw, izit very hard for you to admit it?

keep in mind, this is an open source system, nobody will think that it is a shame.

but if it is a design flaw and you still insist that it is a security features, than SHAME on you!! and pls don't ever involve yourself into an open source, if you can't take it.

And lastly, do you think that all the people here dont understand what is security feature and what is design flaw?

Is there a way to lock bugs from further comments?

(In reply to thyeun from comment #75)
> And lastly, do you think that all the people here dont understand what is
> security feature and what is design flaw?

It's a design flaw in nemo. We've already made it very clear how to implement GUI applications that edit files as root by running the GUI as non-root, and using polkit to perform privileged operations. (This *should* be supported in gedit and nautilus already, but that seems to not, in fact, be the case. I'm trying to figure out what the state of that code is.)

If you open the app as root, you lose themes stored in your home directory, you lose font settings stored in your home directory, you in fact lose all settings stored in your home directory. You also lose your session bus connection, so you lose all features that depend on the session bus. And almost everything needs the session bus for something, e.g. all GNOME apps will lose their integrated app menus, because the app menu is being exported on root's session bus instead of your user's.

This is just fundamentally broken, and there's no way to make it work properly.

all the lose setting you mention, are just happen on wayland. sorry my bad, it should be gnome 3.26.2 with wayland (why it wont happen on xorg?). 

do you try it on ubuntu 16.04? with the same things? see any your so call "lose" happen or not.

why you so scare to let people to commented here?

the more we commented here, end of days, who will be getting the benefit? the benefit end result will be go to wayland, and if it is look good, i'm sure more people will using it.

and why you want to lock this issue up? since over a years until today, non of a good fix been provided.

(In reply to thyeun from comment #77)
 
> and why you want to lock this issue up? since over a years until today, non
> of a good fix been provided.

What do you mean no good fix was provided. The fix should be done in each individual application that needs root.

For example (not yet released) version of Partition Manager now successfully runs without root with polkit and now it runs just fine on Wayland. So some fixes are being done.

Although, to be honest I was able to connect to user session bus even with root application before. The issue is a bit more subbtle than just connecting to session bus. When you run as root, sometimes you need to connect to original user's session bus, sometimes to root's session bus. Similarly, only graphical apps running via XWayland don't start on Wayland (without xhost + and similar workarounds). You can still run root wayland clients on wayland although that is certainly not recommended for security reasons.

Good news, I've submitted a merge-req for mutter to generate and pass an xauth file to Xwayland when starting it fixing this bug:
https://gitlab.gnome.org/GNOME/mutter/merge_requests/626

This has been accepted, so starting with GNOME-3.34 this will no longer be an issue:
https://gitlab.gnome.org/GNOME/mutter/commit/a8984a81c2e887623d69ec9989ae8a5025f7bd47

Awesome work, thanks a lot, Hans! Looking forward to GNOME 3.34.

Indeed this is great work. Thank you Hans.

Reopening and marking ASSIGNED. NEXTRELEASE is inappropriate until it's actually delivered.

Moving to mutter.

while we're playing status bingo, I like POST for 'patch exists or is merged upstream' :)

Correct, I missed that it was merged upstream. I thought the PR was still under review. Thanks!

But is it generic solution? Will it work also for native Wayland apps?

(In reply to Vít Ondruch from comment #86)
> But is it generic solution? Will it work also for native Wayland apps?

No this will only fix sudo for X11 applications.

Running GUI code as root is still a bad idea. Fixing sudo for X11 applications is important because that is a regression for people moving from Xorg to Wayland, IMHO GUI apps which need root rights need to be fixed to not need root rights (by e.g. using a helper daemon + polkit) when they are being ported to become native Wayland apps.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

F31 includes the patch that sets up the Xauth file things. For Wayland clients, it's nothing mutter can do, it's just about having the right env vars set, and whether that is reasonable is a question for another bug. So closing this one as CURRENTRELEASE.

What are the correct env vars to set for Wayland clients?

Running

sudo --preserve-env=XDG_RUNTIME_DIR,WAYLAND_DISPLAY weston-terminal

works here.

Please let me shine some lite on what is really happening here, why this bug appear and why developers act strange.

The root cause of this bug is an architectural problem and it is far from bugs in GUI frameworks.
The gnome-session and wayland compositor are run from the user account. This is the problem! Because of this, applications run from the root account shouldn't output graphics on Wayland compositor or it may be captured by an unprivileged user apps. Linux graphics developers are well aware of this architectural defect but instead of addressing it and run compositor from root (or some other privileged system account) they came up with a horror story about complex and buggy graphics frameworks and are trying to convince users that graphics should be separated from privileged code and configs should be edited in the console running "sudo nano /etc/...". As expected this only makes more problems: 
1) it is very hard to rewrite every program and separate its code into privileged and unprivileged GUI, on this road programmers may introduce even more unintentional backdoors and bugs;
2) users are still trying to run old programs and are running them from even less secure xwayland wrapper with the "xhost si:localuser:root" hack;
3) even if you edit configs in gnome-terminal running "sudo nano /etc/..." its input and output is still passed to the wayland compositor running from the user account and its content can be captured!

Now compare this to *tty sessions (i.e. alt+f<n> consoles), they are run from the root and if you login as root a user wouldn't able to access its output and intercept its input. The same should be done to graphics.

So, Linux GUI developers, please stop terrorize users with this horror story about buggy graphical frameworks and solve the actual architectural problem. Please run wayland compositor from root and let us use it to edit config files with an old graphics editors we like by launching them with sudo.

You do not want the compositor running as root.  That's why there was so much work put into making sure the X server could run as a user instead of root.  They aren't going undo all that with Wayland now.

@Samuel who is that vicious person who decided to expose su bash prompt input and output from gnome-terminal to X server running from under user account? And when it was different? It is not a question that the wayland compositor shall run from root and hide its content from an unprivileged user apps, just like *tty do.