GNOME Bugzilla – Bug 758131
Don't run GUI as root (Was: [wayland] gparted fails to start under wayland)
Last modified: 2017-12-19 17:16:46 UTC
Running gparted on a gnome+wayland session fails: $ gparted_polkit Failed to execute operation: Access denied No protocol specified (gpartedbin:17662): Gtk-WARNING **: cannot open display: :0 Failed to execute operation: Access denied Gparted's polkit dialog is shown, but no gparted window shows up after that. Looks like although the backend runs as root, the GUI must run as non-root user to make this work.
Hi Christian, Which distribution and version are you using? Note that there is a GParted Forum post about this, including all known workarounds and upstream bug reference for Fedora. Topic: [SOLVED] How to run GParted on a GNOME on Wayland desktop http://gparted-forum.surf4.info/viewtopic.php?id=17446 Thanks, Mike
See also: https://bugzilla.redhat.com/show_bug.cgi?id=1266771 From http://gparted-forum.surf4.info/viewtopic.php?id=17446 : > Workarounds: > > Use one of the following workarounds: > > 1) Do not use Wayland. Instead select either "GNOME" or "GNOME Classic" at the login screen. > > 2) Allow all local users to display applications on your desktop. Before running GParted type the following into a terminal window: > > xhost +local: > Works (workaround) for now. > 3) Login to the desktop as root, instead as your normal user. Please don't suggest that to users. Running a desktop session as root is a big security risk! Anyway, if you use one of the workarounds above to start gparted and then press "Help" → "About" (main menu) and click on the URL gparted will open your system default web browser as root. No one should ever run a web browser as root!
Workaround 3 saying login to the desktop as root has been removed from the GParted Forum solution. Is there anything else to be addressed in this bug report? Or can it be closed? Thanks, Mike
I don't know whether you want to change gparted to not run its GUI as root. There are several pros and cons as discussed on the fedora-devel mailing list. In short: Pro GUI as root: + no change to code + less dependencies Con: - Security (see comment #2 above for an example) References: https://lists.fedoraproject.org/pipermail/devel/2015-October/216252.html https://lists.fedoraproject.org/pipermail/devel/2015-November/216275.html https://lists.fedoraproject.org/pipermail/devel/2015-November/216325.html If you don't want to make this change. If not, just close this bug report after fixing the URL/web browser problem. There might be similiar issues around (I don't know that).
GParted is run in two different environments. It is run on a users' Desktop and run from a live rescue distribution. In the case of live rescue disruption they run graphical desktops as root and hence any web browser run by the user also runs as root. Running web browser as root --------------------------- The current code does this: https://git.gnome.org/browse/gparted/tree/src/Win_GParted.cc?h=GPARTED_0_24_0#n1641 //the url is not clickable because this would introduce an new dep //(gnome-vfsmm) dialog.set_website( "http://gparted.org" ); Somewhere between GTK 2.10 and 2.24, GTK itself made this a clickable link which runs the web browser as the user which GParted is running as, i.e. root. I have no idea how to make GParted run the web browser as the logged in user. The only other option I see is to remove the URL from the about box. Running GParted UI as non-root ------------------------------ All the code is predicated on a single process querying the storage, running the GUI and manipulating the storage. It would be a very large task to change. For a spare time only hobby this might never get done. Thanks, Mike
Created attachment 315903 [details] [review] Don't invoke web browser as root (v1) Thank you Christian and Mike for investigating this issue. I agree that invoking a web browser as root is poor security practice. It would be nice to keep the GParted web site link in the about box. What do you think of changing from a clickable website link to a non-clickable website label? I think that such a change would remove the security problem of being able to invoke a web browser as root while still listing the GParted website URL. Curtis
Created attachment 315968 [details] CentOS 5 and Fedora 23 screenshot of before and after about dialog boxes Hi Curtis, Thanks for looking closer and producing a patch for this. Git am reports white space error. Comment line starts space, tab before double slash. I'll fix. A small danger when editing existing lines, getting caught by latent white space errors. When testing I discovered that on CentOS 5, with gtkmm 2.10.10, that the change causes the URL not to be displayed in the about box. Since this is really old we should just leave it as it is and not try to work around it. With CentOS 6, with gtkmm 2.18.2, the URL is shown but not clickable as expected. Picture of CentOS 5 and Fedora 23 desktops each showing about dialog before in top left and after in bottom right attached. If your OK with this I'll push upstream. Mike
I guess this issue also affects opening help. There is no way to open yelp in another way here so I don't know how this could be fixed.
Thanks Mike for reviewing the patch and fixing the white space error. You have my agreement to push the patch. Regarding opening yelp, I too do not know of another way to invoke help. As Mike mentioned in comment #5, we develop GParted as a spare time hobby so refactoring the code to run the GParted UI as non-root might never happen. I think we at least got rid what might be considered the worst security hole of the web browser running as root.
The following patch can now be found in the public GParted GIT repo. Thanks, Mike Make about dialog website link non-clickable (#758131) https://git.gnome.org/browse/gparted/commit/?id=5b0465e9a39004f6c7b061a36aaa8df06adbce3b
This enhancement was included in the GParted 0.25.0 release on January 18, 2016.
> I have no idea how to make GParted run the web browser as the logged in user. The only other option I see is to remove the URL from the about box. You can try forking and drop root to user pointed by SUDO_UID and PKEXEC_UID variables. No such variables will be in place if neither of them are used. In case of LiveCD, you can use nobody user(UID -1).