Xwayland not using XAUTHORITY, prevents root applications from connecting

[Wise Melon]

When running wayland, GDM fails to set up an XAUTHORITY file and instead
relies on the process UID for authentication. This prevents
applications run as root, like gparted or synaptic from connecting to
the server. GDM needs to set up the XAUTHORITY file when running
Xwayland just like it does when it runs the conventional Xorg.

A large list of applications broken by this can be found here:

https://codesearch.debian.net/search?q=Exec%3Dsu-to-root+filetype%3Adesktop+path%3A*%2Fapplications%2F*&perpkg=1

openSUSE handles this issue with this patch (from the changelog, it looks like they implemented this for their YaST settings app):
https://build.opensuse.org/package/view_file/GNOME:Factory/mutter/mutter-xwayland-create-xauthority.patch?expand=1

[Wise Melon (wise-melon-deactivatedaccount)]

I have found that after switching from Xorg to Wayland on Ubuntu GNOME 16.10 with GNOME 3.22 that GParted does not run when I try to run it as root. That is when I click the icon and enter my password nothing happens. I have found that when running what is run when the icon is clicked that the output in Terminal is (gparted-pkexec):

    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/run-user-1000.mount → /dev/null.
    Created symlink /run/systemd/system/run-user-120.mount → /dev/null.
    Created symlink /run/systemd/system/tmp.mount → /dev/null.
    No protocol specified

    (gpartedbin:16832): 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/run-user-1000.mount.
    Removed /run/systemd/system/run-user-120.mount.
    Removed /run/systemd/system/tmp.mount.

So I am now unable to launch and use GParted as root which is really the only way I can run it in order to make changes.

I originally reported this issue here: https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/1652282 But thought I should also do so upstream.

[Mike Fleetwood (mfleetwo)]

This is a known limitation and design choice that Wayland doesn't allow
root privileged applications to work.

One workaround is to run the following in a terminal before running
GParted to allow root applications to connect to the X server under
Wayland.
  xhost +si:localuser:root

Another workaround it to continue to use the X.org display server rather
than the Wayland display server.

More information can be found in the:
  Common Fedora 25 Bugs / Running graphical apps with root privileges
  (e.g. gparted) does not work on Wayland
  https://fedoraproject.org/wiki/Common_F25_bugs#wayland-root-apps

[Mike Fleetwood (mfleetwo)]

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

[Nate Graham (pointedstick)]

Those workarounds are fine for now, but the real solution to boldly move us all into the Wayland future is to make GParted run its main UI as a normally-privileged user, and only request elevated permissions for actions that actually require them.

[Curtis Gedak (gedakc)]

Hi Nate,

For past discussion on this issue, see also:

Bug 758131 - Don't run GUI as root
             (Was: [wayland] gparted fails to start under wayland)

Curtis

[Nate Graham (pointedstick)]

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

Sadly that will eventually result in GParted dying as more and more distros move to Wayland. :(

[Phillip Susi (psusi)]

And can you run any other Xwindows app as root? What if you try running gpartedbin directly from a root shell?

[Wise Melon (wise-melon-deactivatedaccount)]

No, this is a security feature in Wayland, it's not meant to allow windows to run as root. This has already been established in the upstream report.

[Wise Melon (wise-melon-deactivatedaccount)]

@Phillip, This is an intended policy and it is there for security reasons so rather than decreasing security standards, I think it would be best for GParted to simply meet them.

[Erkin Alp Güney (erkinalp9035)]

> For a spare time only hobby this might never get done.

Curtis, transferring maintenance of GParted to GNU or GNOME teams would solve that. They have long queues for maintenance requests and it is able to finish the process (find a full time maintainer) in a fortnight.

[Jeremy Bícha (jbicha)]

It was announced today that the Ubuntu Desktop Team currently intends to default to GNOME on Wayland for Ubuntu 18.04 LTS.

[Phillip Susi (psusi)]

GParted, and plenty of other applications must be run as root, period. Wayland needs to accommodate this just as X always has.

[Jeremy Bícha (jbicha)]

Phillip, please stop changing the bug title because the original bug title was correct.

GParted can be changed to make admin changes without having to run the entire UI as root.

Do you want to discuss this in #ubuntu-desktop on IRC or on the ubuntu-desktop mailing list?

[Wise Melon (wise-melon-deactivatedaccount)]

@Phillip, Wayland actually does accommodate it, I have an Arch system where it works perfectly fine with running GParted as root. The reason it doesn't work on Ubuntu is not completely because of Wayland, but rather because of how Wayland has been set up by the Ubuntu GNOME team. Which is intentional for security. I don't know, but you might be able to disable this since it's probably somewhere in the configuration. I don't know, I just know that on Arch there is no issue with this with the standard Wayland.

[corrado venturini (corradoventu)]

Same problem on Ubuntu 17.10 gnome wayland

corrado@corrado-HP-aGnome:~$ uname -a
Linux corrado-HP-aGnome 4.10.0-20-generic #22-Ubuntu SMP Thu Apr 20 09:22:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
corrado@corrado-HP-aGnome:~$ gparted
Root privileges are required for running gparted.
corrado@corrado-HP-aGnome:~$ sudo gparted
[sudo] password for corrado:
Created symlink /run/systemd/system/-.mount → /dev/null.
Created symlink /run/systemd/system/boot-efi.mount → /dev/null.
Created symlink /run/systemd/system/run-user-1000.mount → /dev/null.
Created symlink /run/systemd/system/run-user-120.mount → /dev/null.
Created symlink /run/systemd/system/tmp.mount → /dev/null.
No protocol specified

(gpartedbin:2315): Gtk-WARNING **: cannot open display: :0
Removed /run/systemd/system/-.mount.
Removed /run/systemd/system/boot-efi.mount.
Removed /run/systemd/system/run-user-1000.mount.
Removed /run/systemd/system/run-user-120.mount.
Removed /run/systemd/system/tmp.mount.
corrado@corrado-HP-aGnome:~$

[Gnome-4 (gnome-4)]

(In reply to Erkin Alp Güney from comment #6)
> > For a spare time only hobby this might never get done.
>
> Curtis, transferring maintenance of GParted to GNU or GNOME teams would
> solve that. They have long queues for maintenance requests and it is able to
> finish the process (find a full time maintainer) in a fortnight.

Sounds like a whole lot of irony. Anyway, they also have gnome-disks, which has less features and a more "modern" UI.

[Erkin Alp Güney (erkinalp9035)]

gnome-disks is completely different. It is a frontend to udisks.

[Mike Fleetwood (mfleetwo)]

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

[Mike Fleetwood (mfleetwo)]

@Nikita, Can you point me at any details on how your Arch Linux system
allows GParted to run as root under Wayland. On my Arch Linux VM with
GNOME on Wayland and GParted package I still have to do
"xhost +SI:localuser:root" to allow root processes to connect to the
XWayland display.

[Wise Melon (wise-melon-deactivatedaccount)]

@Mike, I am afraid that I don't know, all I know is it worked as I described previously until a recent update and now GParted no longer runs as root under Wayland. So it was either a bug they fixed, a new feature implemented in some way, or they changed the default configuration. If I find out the answer, I will let you know.

[Mikhail Gavrilov (mikegav)]

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. This needed for supporting modern Linux distributives wich migrated to Wayland.

Please read comments 33, 36 and 37
https://bugzilla.redhat.com/show_bug.cgi?id=1274451#c33

[sudodus (nio-wiklund)]

I see the same problem in Ubuntu Artful (to become 17.10), when running with Wayland. See the following links

https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1706146

https://ubuntuforums.org/showthread.php?t=2366995

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1652282

[Mike Fleetwood (mfleetwo)]

Created attachment 357573
Interim workaround for display access (draft 1)

Hi Curtis,

Here's an interim workaround for this bug. The patchset is only draft
because of an installation issue / dilemma with the location of the
polkit action file. More on that below.

Suggested NEWS fragments describing the change
==============================================

Release Notes
-------------

Provides an interim workaround to allow GParted to run under Wayland by
using xhost to grant and revoke root access to the X11 display. This
must be enabled while building the software with:
    ./configure --enable-xhost-root

Pkexec from Polkit has been made the first choice graphical SU program
as all the desktops have settled on using Polkit as the privileged
access mechanism. Also execution of the graphical SU program has been
moved from gparted.desktop to the gparted shell wrapper. Therefore
gparted can be run either by an unprivileged user or by root and as such
is installed in $prefix/bin rather than $prefix/sbin. This additionally
means distributions can drop their pkexec scripts used to launch
gparted.

Dependencies (new/updated)
--------------------------
  * Uses pkexec command (part of polkit) for root privilege escalation
    when available.
  * Uses xhost command to grant and revoke root access to the display
    when configured to do so.

Issue / dilemma with polkit action file installation location
=============================================================

The ./Makefile.am contains this line:
    polkit_actiondir = /usr/share/polkit-1/actions
from this commit in the patchset:
    Add required polkit action file (#776437)

This is to install the gparted polkit action file into that location,
the only location which polkit looks for action files. (See the above
mentioned commit comment for more details). Without it being there
polkit won't authorise GParted to run as root.

However that setting breaks 'make distcheck' because it doesn't install
the file in the ./gparted-$version/_inst and is against GNU programming
standards for program installations. [1][2] To make 'make distcheck'
work and satisfy the standards it should be:
    polkit_actiondir = $(datadir)/polkit-1/actions
But with the default prefix being /usr/local it will install the file
into /usr/local/polkit-1/actions and fail authorising GParted as
detailed above.

So you can either have 'make install' do the needed thing or make have
'make distcheck' work, not both!

[1] Automake Manual, 27.10 Installing to Hard-Coded Locations
https://www.gnu.org/software/automake/manual/automake.html#Hard_002dCoded-Install-Paths

[2] GNU Coding Standards, 7.2.5 Variables for Installation Directories
https://www.gnu.org/prep/standards/standards.html#Directory-Variables

I have also looked at some other packages which install polkit action
files. They seem to use polkit_actiondir = $(datadir)/polkit-1/actions
so I assume only produce an installion with the polkit action file
installed correctly when prefix = /usr. [3][4][5][6]

[3] gnome-settings-daemon plugins/power/Makefile.am
        polkit_policydir = $(datadir)/polkit-1/actions
https://github.com/GNOME/gnome-settings-daemon/bl...

[Curtis Gedak (gedakc)]

Hi Mike,

The draft patch in comment #11 looks pretty good to me. I did observe two locations in the comment of P 4/7 "Add required polkit action file" where "install" should be "installed".

  Note that all polkit action files must be install in
                                            ^^^^^^^
  <snip>
  packages, action files must always be install in the same location.
                                        ^^^^^^^

I applaud your choice to require packagers to manually enable the --enable-xhost-root configure option. That way they make a conscious choice to enable the work-around to run on Wayland. Otherwise the default is not to use xhost.

I tested on fedora 25.

With --enable-xhost-root, gparted successfully runs.
Without --enable-xhost-root, gparted fails to run as it cannot open the display.

I also confirmed the issue regarding "make distcheck". It's too bad that we can't have it work both ways, but I do understand the dilemma.

Curtis

[Curtis Gedak (gedakc)]

Hi Mike,

I forgot to mention another suggestion for the draft patch. We should consider including additional generated files in the .gitignore file.

Some possible candidates are:

  .dirstamp
  org.gnome.gparted.policy
  org.gnome.gparted.policy.in

Curtis

[Mike Fleetwood (mfleetwo)]

Hi Curtis,

To keep you up to date; I have just asked in the automake email list to
see if there are any alternative solutions to the above polkit
installation location dilemma.[1]

I will address the spelling issue and .gitignore entries in the next
round of updates.

Mike

[1]
Not installing to hard-coded locations vs polkit's fixed location
http://lists.gnu.org/archive/html/automake/2017-08/msg00015.html

[Mike Fleetwood (mfleetwo)]

Created attachment 358405
Interim workaround for display access (v1)

Hi Curtis,

Here is patchset v1 ready for fully review. Compared to draft 1 from
comment #11 the changes are:
* Incrementally updates the README file in a number of patches for
  various changes.
* P4/9 "Add required polkit action file"
** Installs polkit action file into $(datadir)/polkit-1/actions so
   make distcheck works, but needs to be manually installed when prefix
   is other than /usr.
** Documents this in the README file.
** Mark relevant strings in and the file org.gnome.gparted.policy.in.in
   for translation.
** Increases minimum intltool to 0.36.0 in configure.ac because of the
   use of INTLTOOL_POLICY_RULE in Makefile.am.
** Adds .gitignore entries for new build files
   org.gnome.gparted.policy{,.in}.
* P6/9 "Check for pkexec >= 0.102 which supports execution of X11..."
  moves before P8/9 "Only when configured, grant root access to the..."
* Adds new patches:
  P7/9 "Remove unnecessary autoconf check for pkexec --disable-inter..."
  P9/9 "Add .dirstamp to .gitignore"
* Minor commit wording updates and corrections.

Testing:
1) On Ubuntu 16.10 using Wayland display that configuring with
   --enable-xhost-root allows gparted run as normal user to display and
   without the config option gparted is not allowed to display.
   Note:
   sudo doesn't grant access to the X11 server under Wayland display so
   sudo gparted doesn't work. Have to run gparted as normal user to
   allow it to use xhost to grant root access to the display.
2) On Fedora 26 using Wayland display same results when configured with
   and without --enable-xhost-root.
3) On CentOS 7 with X11 display and configured without
   --enable-xhost-root allows gparted run as normal user and as root to
   display.
4) That make && make distcheck works for every commit.

Thanks,
Mike

[Curtis Gedak (gedakc)]

Hi Mike,

I've just started reviewing the patch set from comment #15.

Following is the first issue I've encountered when building on kubuntu 16.04:

$ make distcheck
<snip>
INTLTOOL_EXTRACT="/usr/bin/intltool-extract" XGETTEXT="/usr/bin/xgettext" srcdir=../../../po /usr/bin/intltool-update --gettext-package gparted --pot
rm -f missing notexist
srcdir=../../../po /usr/bin/intltool-update -m
The following files contain translations and are currently not in use. Please
consider adding these to the POTFILES.in file, located in the po/ directory.

sub/org.gnome.gparted.policy.in

If some of these files are left out on purpose then please add them to
POTFILES.skip instead of POTFILES.in. A file 'missing' containing this list
of left out files has been written in the current directory.
Please report to https://bugzilla.gnome.org/enter_bug.cgi?product=gparted
if [ -r missing -o -r notexist ]; then \
  exit 1; \
fi
Makefile:209: recipe for target 'check' failed

This issue is not holding me up and I will continue with my review and testing.

Curtis

[Mike Fleetwood (mfleetwo)]

Hi Curtis,

It looks like the make distcheck failure is another repeat of an
intltool bug we have had to workaround before:
https://git.gnome.org/browse/gparted/commit/?id=4cc5103dbdd42583c3ce7481e0e4f08d16e2009a

After fixing that make distcheck still fails though:

$ make distcheck
...
 ( cd '/home/ubuntu/programming/c/gparted/gparted-0.29.0-git/_inst/share/polkit-1/actions' && rm -f org.gnome.gparted.policy )
make[2]: Leaving directory '/home/ubuntu/programming/c/gparted/gparted-0.29.0-git/_build/sub'
make[1]: Leaving directory '/home/ubuntu/programming/c/gparted/gparted-0.29.0-git/_build/sub'
make[1]: Entering directory '/home/ubuntu/programming/c/gparted/gparted-0.29.0-git/_build/sub'
ERROR: files left after uninstall:
./share/icons/hicolor/icon-theme.cache
Makefile:892: recipe for target 'distuninstallcheck' failed
make[1]: *** [distuninstallcheck] Error 1
make[1]: Leaving directory '/home/ubuntu/programming/c/gparted/gparted-0.29.0-git/_build/sub'
Makefile:836: recipe for target 'distcheck' failed
make: *** [distcheck] Error 1

Investigation continues.

Mike

[Curtis Gedak (gedakc)]

Hi Mike,

Thank you for this updated patch set.

From a visual review I discovered only two minor typos to consider
fixing:

P4/9 - Add required polkit action file (#776437)

  intltool to 0.36.0 where it was first introduced in intllool.m4. This
                                                         ^^^
  intltool to 0.36.0 where it was first introduced in intltool.m4. This

P8/9 - Only when configured, grant root access to the X11 display (#776437)

  As an interim workaround make the gparted shell wrapper uses xhost to
                                                            ^^^
  As an interim workaround make the gparted shell wrapper use xhost to

My testing has gone fairly well. Other than the issue with 'make
distcheck', gparted is able to run on both X11 and Wayland with this
patch set.

Following are my test steps and results.

Compile with:
  $ ./configure --enable-xhost-root --prefix=/usr
  $ make
  # make install

Run with:
  gparted | sudo gparted | gparted.desktop (menu)
OR
  gparted | su -c "gparted" | gparted.desktop (menu)

Test Results:

Distro gparted sudo gparted gparted.desktop
------------ ---------------- ------------ ----------------
Debian 7 Works Works Root needed msg
Debian 9 ### Issues compiling - Bad VM??? ###
Fedora 24 Works Works Works
Fedora 25 Works Can't open display Works
openSUSE 42.1 Works Can't open display Works
openSUSE 42.2 Works Can't open display Works
Ubuntu 14.04 Root needed msg Works Root needed msg
Ubuntu 17.04 Works Works Works

Curtis

[Mike Fleetwood (mfleetwo)]

Created attachment 358687
Interim workaround for display access (v2)

Hi Curtis,

Here's patchset v2. It fixes make distcheck failure by adding
sub/org.gnome.gparted.policy.in to POTFILES.skip and corrects the
spelling mistakes.

My second distcheck failure was because I was doing a parallel make,
'make -j 2 distcheck' which was leading to ERROR: files left after
uninstall. Doing a single threaded 'make distcheck' works successfully.

Thanks,
Mike

[Curtis Gedak (gedakc)]

Hi Mike,

Thanks the updated patch set. My testing has gone well, with no new
issues to report.

Following are my test steps and additional distro results.

Compile with:
  $ ./configure --enable-xhost-root --prefix=/usr
  $ make
  # make install

Run with:
  gparted | sudo gparted | gparted.desktop (menu)
OR
  gparted | su -c "gparted" | gparted.desktop (menu)

Test Results:

Distro gparted sudo gparted gparted.desktop
------------ ---------------- ------------ ----------------
Debian 9 [1] Works Works Works
openSUSE 42.3 Works Can't open display Works
Ubuntu 16.04 Works Works Works

[1] My previous Debian 9 VM was indeed broken. A newly built VM has
    no issues when compiling GParted.

Mike, in comment #11 you provided some suggested text for the NEWS announcement.
Are there any changes or updates you would like made now that the patch set is working as expected?

Provided there are no objections I will commit patch set v2 from
comment #19 in the next day or so.

Curtis

[Mike Fleetwood (mfleetwo)]

Hi Curtis,

Push patchset v2 upstream when ready.

Thank you for your through testing on lots of distros.

The results on Ubuntu 14.04 LTS look odd though.
> Distro gparted sudo gparted gparted.desktop
> ------------ ---------------- ------------ ----------------
> Ubuntu 14.04 Root needed msg Works Root needed msg

That would be the case if no graphical SU program was found during
configure. My Ubuntu 14.04 LTS (XFCE) VM does have polkit 0.105
installed and pkexec is found during configure. I did both:
    ./configure --prefix=/usr/local
    ./configure --prefix=/usr/local --enable-xhost-root
along with additionally installing the action file:
    sudo install -m 644 org.gnome.gparted.policy \
         /usr/share/polkit-1/actions/org.gnome/gparted.local.policy
and made sure that I uninstalled Ubuntu provided gparted package (so
that there was only one gparted.desktop file for the desktop to choose
from and/or display). In both cases (with and without
--enable-xhost-root) it all worked.

Distro gparted sudo gparted gparted.desktop
------------ ---------------- ------------ ----------------
Ubuntu 14.04 Works Works Works

Here's an updated Release Notes section of NEWS mentioning about
possibly having to manually install the polkit action file.

Release Notes
-------------

Provides an interim workaround to allow GParted to run under Wayland by
using xhost to grant and revoke root access to the X11 display. This
must be enabled while building the software with:
    ./configure --enable-xhost-root

Pkexec from polkit has been made the first choice graphical SU program
as all the desktops have settled on using polkit as the privileged
access mechanism. See "Installing polkit's Action File" section in the
README file for when an additional installation step may be needed.
Also execution of the graphical SU program has been moved from
gparted.desktop to the gparted shell wrapper. Therefore gparted can be
run either by an unprivileged user or by root and as such is installed
in $prefix/bin rather than $prefix/sbin. This additionally means
distributions can drop their pkexec scripts used to launch gparted.

Thanks,
Mike

[Curtis Gedak (gedakc)]

Hi Mike,

Thank you for the updated NEWS text and for the tip about your Ubuntu
14.04 testing.

I investigated and discovered that I had installed an older version
into /usr/local. Since this older version was first in the path, my
tests were running the older version. Testing with only patch set v2
installed revealed the same results as you (it all worked).

Following are some changes I made to the NEWS announcement to try to
highlight that installation locations are different. Please feel free
to suggest further updates.

*** BEGIN ***

ATTENTION PACKAGERS:

The install location has changed for both the gparted script and the
gpartedbin executable.

This release provides an interim workaround to allow GParted to run
under Wayland by using xhost to grant and revoke root access to the
X11 display. This must be enabled while building the software with:

    ./configure --enable-xhost-root

Pkexec from polkit has been made the first choice graphical SU
program as all the desktops have settled on using polkit as the
privileged access mechanism. See "Installing polkit's Action File"
section in the README file for when an additional installation step
may be needed.

Also changed is that execution of the graphical SU program has been
moved from gparted.desktop to the gparted shell wrapper. Therefore
gparted can be run either by an unprivileged user or by root and as
such is installed in $prefix/bin rather than $prefix/sbin. This
additionally means distributions can drop their pkexec scripts used
to launch gparted.

*** END ***

Patch set v2 from comment #19 has been committed to the git repository
for inclusion in the next release of GParted.

The relevant git commits can be viewed at the following links:

Move root privilege escalation into gparted wrapper script (#776437)
https://git.gnome.org/browse/gparted/commit/?id=a2cc5014c652a7e15b5460fa58d9680d146c6be4

Now install gparted wrapper script into $prefix/bin (#776437)
https://git.gnome.org/browse/gparted/commit/?id=778e21e94c9c5608a7087f31f1491e5744b864b8

Add detection of pkexec root privilege escalation program (#776437)
https://git.gnome.org/browse/gparted/commit/?id=b47528b6f976633b49be192ab8e4e8455f95b6e4

Add required polkit action file (#776437)
https://git.gnome.org/browse/gparted/commit/?id=f35e734a0c21869c5cdff61ffb2b5724e6ae431b

Only install polkit action file when pkexec is used (#776437)
https://git.gnome.org/browse/gparted/commit/?id=2f559ec3b5a95f8781979c80bd260ad952645f36

Check for pkexec >= 0.102 which supports execution of X11 apps (#776437)
https://git.gnome.org/browse/gparted/commit/?id=11c251293e6fd156b57905409efc5464bd85b202

Remove unnecessary autoconf check for pkexec --disable-internal-agent option (#776437)
https://git.gnome.org/browse/gparted/commit/?id=6f521c4d98e0fd6a33e40bd5910aacda89564126

Only when configured, grant root access to the X11 display (#776437)
https://git.gnome.org/browse/gparted/commit/?id=f38ccd028425552a1116180387e5307f23b8a688

Add .dirstamp to .gitignore
https://git.gnome.org/browse/gparted/commit/?id=576d0f7cbf5a8ef61840f17315e8c7b3f66d7a65

Curtis

[Mike Fleetwood (mfleetwo)]

Hi Curtis,

(In reply to Curtis Gedak from comment #22)
> ATTENTION PACKAGERS:
>
> The install location has changed for both the gparted script and the
> gpartedbin executable.

Only the install location of the gparted script has changed to
$prefix/bin. The gpartedbin executable is still installed in
$prefix/sbin as it always has.

For an ATTENTION PACKAGES sentence I would say this:

  The installation location of the gparted script has changed and
  package scripts calling pkexec can be dropped.

Thanks,
Mike

[Curtis Gedak (gedakc)]

Thanks Mike for the ATTENTION PACKAGERS correction. I have made this change in the NEWS file I am building for our next release.

Curtis

[Curtis Gedak (gedakc)]

This enhancement was included in the GParted 0.30.0 release on October 10, 2017.

[Strangiato Xanadu (strangiato)]

Just updated to 0.30 on Arch, Wayland session...
Clicking shell icon gparted shows a message "...only root can run it".

I get "(gpartedbin:24508): Gtk-WARNING **: cannot open display: :0"
running "sudo gparted" from terminal.

[Curtis Gedak (gedakc)]

Hi Strangiato,

"sudo gparted" does not work on all distros (see test results starting in comment #18).

First ensure that all older versions of GParted are removed.

Next compile and install with:

  ./configure --prefix=/usr --enable-xhost-root
  make
  sudo make install

Then run gparted with:

  gparted

'Hope that helps.

Curtis

[Strangiato Xanadu (strangiato)]

In my previous comment I said "just updated". Sorry, my mistake.
I just installed it from Arch testing repositories,
no previous gparted release was installed.

[Curtis Gedak (gedakc)]

Hi Strangiato,

If you are using GParted from a distro repository, such as Arch, and experience problems then I suggest you raise the issue with that distro.

Curtis

[steve lubbs (slubbs)]

Gparted does not work as of 17.10 with updates up to 10/27/2017. What gives??

[Gustav Ekner (gustav-ekner)]

The issue is fixed in gparted version 0.30, but not in the latest ubuntu package which is of version 0.28 in artful. Also, according to https://bugzilla.gnome.org/show_bug.cgi?id=776437, the package must be compiled with --enable-xhost-root. It would be great if the maintainer (Curtis Gedak) could take a look at this.

[Jeremy Bícha (jbicha)]

Actually, Ubuntu is unlikely to enable that hack. Please just log in to Ubuntu on Xorg if you want to run GParted. Or try the GNOME Disks app which is installed by default and works with Wayland.

[Jose Barakat (josebarakat)]

Same thing...

jose@jose-Lenovo-G400s:~$ uname -a
Linux jose-Lenovo-G400s 4.13.4-041304-generic #201709270931 SMP Wed Sep 27 13:35:03 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

jose@jose-Lenovo-G400s:~$ echo $DISPLAY
:0

Phoronix Test Suite v7.4.0
Interactive Benchmarking
System Software / Hardware Information
Hardware:
Processor: Intel Core i3-3110M @ 2.40GHz (4 Cores), Motherboard: LENOVO, Chipset: Intel 3rd Gen Core DRAM, Memory: 6144MB, Disk: 500GB Seagate ST500LT012-9WS14 + 16GB Cruzer Edge, Graphics: Intel Ivybridge Mobile 1536MB (1000MHz), Audio: Conexant CX20757, Network: Qualcomm Atheros QCA8172 Fast + Qualcomm Atheros AR9485 Wireless
Software:
OS: Ubuntu 17.10, Kernel: 4.13.4-041304-generic (x86_64), Desktop: GNOME Shell 3.26.1, Display Server: Wayland, Display Driver: modesetting 1.19.3, OpenGL: 4.2 Mesa 17.2.2, Compiler: GCC 7.2.0, File-System: ext4, Screen Resolution: 1366x768

jose@jose-Lenovo-G400s:~$ sudo gparted
[sudo] password for jose:
Created symlink /run/systemd/system/-.mount → /dev/null.
Created symlink /run/systemd/system/media-jose-myData.mount → /dev/null.
Created symlink /run/systemd/system/media-jose-SanDisk16GB.mount → /dev/null.
Created symlink /run/systemd/system/run-user-1000.mount → /dev/null.
Created symlink /run/systemd/system/snap-anbox\x2dinstaller-17.mount → /dev/null.
Created symlink /run/systemd/system/snap-core-2898.mount → /dev/null.
Created symlink /run/systemd/system/snap-core-3017.mount → /dev/null.
Created symlink /run/systemd/system/snap-core-3247.mount → /dev/null.
Created symlink /run/systemd/system/snap-wavebox-26.mount → /dev/null.
Created symlink /run/systemd/system/snap-wavebox-32.mount → /dev/null.
Created symlink /run/systemd/system/tmp.mount → /dev/null.
No protocol specified

(gpartedbin:12371): Gtk-WARNING **: cannot open display: :0
Removed /run/systemd/system/-.mount.
Removed /run/systemd/system/media-jose-myData.mount.
Removed /run/systemd/system/media-jose-SanDisk16GB.mount.
Removed /run/systemd/system/run-user-1000.mount.
Removed /run/systemd/system/snap-anbox\x2dinstaller-17.mount.
Removed /run/systemd/system/snap-core-2898.mount.
Removed /run/systemd/system/snap-core-3017.mount.
Removed /run/systemd/system/snap-core-3247.mount.
Removed /run/systemd/system/snap-wavebox-26.mount.
Removed /run/systemd/system/snap-wavebox-32.mount.
Removed /run/systemd/system/tmp.mount.

jose@jose-Lenovo-G400s:~$ sudo synaptic
No protocol specified
Unable to init server: No se pudo conectar: Conexión rehusada

(synaptic:12450): Gtk-WARNING **: cannot open display: :0

jose@jose-Lenovo-G400s:~$ synaptic
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
Violación de segmento (`core' generado)

[Note: Synaptic without sudo didn't started, but crashed]

jose@jose-Lenovo-G400s:~$ sudo nautilus
No protocol specified
Unable to init server: No se pudo conectar: Conexión rehusada

jose@jose-Lenovo-G400s:~$ nautilus
sys:1: PyGIWarning: Nautilus was imported without specifying a version first. Use gi.require_version('Nautilus', '3.0') before import to ensure that the right version gets loaded.
Nautilus-Share-Message: Called "net usershare info" but it failed: Falló a...

[Phillip Susi (psusi)]

It appears to me that the issue is with gdm3. Its man page says it is supposed to create an XAUTHORITY file and set the environment variable to point to it. When running wayland, it does not do this and instead relies on authenticating clients by the UID of the process. It should not be doing this.

[sudodus (nio-wiklund)]

There are workarounds for GUI programs with elevated permissions in Wayland. See these links

https://askubuntu.com/questions/961967/why-dont-gksu-gksudo-or-launching-a-graphical-application-with-sudo-work-with-w

https://wiki.ubuntu.com/Wayland/gks

[Jeremy Bícha (jbicha)]

Philip, please file a bug with GNOME about that issue.

[Dave Stroud (bigdavesr)]

(xhost si:localuser:root) Is a work around I found on fedora forum. Only problem is it has to be used every time you boot up.This is happening with any program that uses root. It is a game breaker for wayland.

[sudodus (nio-wiklund)]

@Dave Stroud,

If you spend a few minutes to create/install/modify some file(s), for example 'gks' according to my previous comment, you need not type 'xhost si:localuser:root' every time you boot up.

1. Some of us think that this is an unnecessary complication or worse,

2. Some of us think that it is an important step to increase the security,

to prevent GUI programs to run with elevated permissions. The developers of Wayland belong to the second group ;-)

-o-

I think that the main linux distros will gradually adjust to the opinion of their users ...

[Phillip Susi (psusi)]

It is a shame that you are unwilling to make a simple configuration change to prevent a completely broken experience for your users. People get very frustrated when they try to open an application and nothing happens. No error message; nothing. All because of a silly default policy. This is not a very Ubuntu thing to do.

[Wise Melon (wise-melon-deactivatedaccount)]

I am afraid that this is a Wayland security feature and that it is not going to be removed just because some users don't like it or don't understand why it is there. As a workaround you can just carry on using Xorg, but under Wayland the program has to be adapted in order not to run the whole program and GUI as root but rather just the specific things within it that need that.

I'm not sure that there actually is anything the Ubuntu people can actually do about this though unless they hack at Wayland and make it less secure. If you want to change Wayland then file an upstream report about this. Ubuntu is really just packaging and redistributing this stuff.

[Wise Melon (wise-melon-deactivatedaccount)]

So, basically, Wayland doesn't allow something really insecure where the whole GUI and everything has root privileges, so it doesn't allow insecure applications to gain root access, however a program can be easily adapted (depending on how it's written) in order to be secure and then you will be able to run it as normal under Wayland. For instance etherape recently got adapted and you just have to now run it like so "sudo etherape -Z username" and then it runs in a way Wayland finds secure and thus it runs as normal as a GUI program but it just runs the GUI as the normal specified user and only the necessary components as root.

Anyway, has GParted upstream released a fix for this? Programs just have to match the new security standards in order to run. That's all, they will have to change and then your experience will be fine again. But I don't think you're going to be able to lessen the Wayland standards, instead take this up with the other developers so that they make their programs meet those standards.

[sudodus (nio-wiklund)]

@Nikita Yerenkov-Scott,

I think your comments about Wayland and security are explaining things in a very good way.

I have already tried to think and act along these ideas: the current version of mkusb works in Wayland. Originally I made it work remotely via ssh by running things that need elevated permissions in text mode (simply by calling sub-shellsripts with sudo), while the main shellscript is using a GUI. It was not too difficult to do. The mileage might vary depending on the structure of the software.

[Dave Stroud (bigdavesr)]

when has synaptic package manager ever been a security risk?Waylan allows software updater to work so should it allow synaptic to work in root.You cant even get root terminal to work.I do not believe that I should to have do work arounds to make it work. It just should work like it always has.

[Jeremy Bícha (jbicha)]

Dave, if you want things to work exactly as they used to work, just log out and log in to the 'Ubuntu on Xorg' session.

[Phillip Susi (psusi)]

No, you misunderstand. Wayland applications running as root work just fine under Wayland. It is X11 applications that do not work, and the reason it does not work is because gdm misconfigures Xwayland. The gdm man page says it does one thing, but it in fact does another, therefore, it is broken.

[Wise Melon (wise-melon-deactivatedaccount)]

@Phillip, I am afraid that this is the new standard and it's not going to change. Just use Xorg if you don't like it. But anyway, soon applications will all upgrade their source code, and then when they meet the set requirements they will all work as before. Just more securely.

So please stop changing the title. You're just being a nuisance.

[Wise Melon (wise-melon-deactivatedaccount)]

@Phillip,

Oh, sorry, for some reason the interface messed up and only showed me that you changed the title. Sorry about that, it's now seemingly preventing me for some silly reason from changing the title back. Wonder if you could do that again? Sorry this is a little awkward.

[Wise Melon (wise-melon-deactivatedaccount)]

Ok, it worked now.

[Jeremy Bícha (jbicha)]

> Wayland applications running as root work just fine under Wayland. It is X11 applications that do not work

I don't think that's true.

[Wise Melon (wise-melon-deactivatedaccount)]

@Jeremy, Yes, from what I've heard, that doesn't sound quite right either. However I really have no idea so I'll let you guys deal with this.

[Dave Stroud (bigdavesr)]

Wayland is now looking into this Dont know what they will do yet.In the meantime I have found that if you insert (xhost si:localuser:root) into start up applications it will work without having to do it in terminal every time you start up.

[Phillip Susi (psusi)]

No, it is NOT the new standard since as I have said, wayland apps have no issue running as root. Applications will NOT be totally rewritten to split off the parts that need root into a separate program. YOU stop changing the title, YOU are being a nuisance: this does not just affect gparted. In fact, gparted has now worked around the issue by automatically running xhost to fix the broken configuration.

Jeremy, you can easily see it is true by simply suing to root and running any native wayland ( gdm3 ) application ( like gedit ). It works just fine.

As long as gdm3 continues to NOT perform the Xauthority configuration its man page says it is supposed to, it is a bug in gdm3.

[Jeremy Bícha (jbicha)]

$ sudo su
root@mycomputer:/home/me# gedit
No protocol specified
Unable to init server: Could not connect: Connection refused

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

=====
And that's the problem here. When gparted is ported to gtk3, the xhost workaround will stop working. And there's no incentive for GNOME to fix apps to run as root under XWayland, if they won't be able to under Wayland. GNOME wants to *encourage* apps to upgrade from gtk2 to gtk3 to get native Wayland support, better HiDPI support and several other features and improvements.

Therefore, I'm closing this bug. Sorry.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Curtis Gedak (gedakc)]

> And that's the problem here. When gparted is ported to gtk3, the
> xhost workaround will stop working.

When/if GParted is ported to gtk3, THEN the work around can be removed.

In the mean time the xhost workaround enables people to continue using GParted.

[Phillip Susi (psusi)]

On 12/7/2017 3:39 PM, Jeremy Bicha wrote:
> $ sudo su
> root@mycomputer:/home/me# gedit
> No protocol specified
> Unable to init server: Could not connect: Connection refused
>
> (gedit:4492): Gtk-WARNING **: cannot open display: :0

sudo defaults to scrubbing the environment; use sudo -E gedit instead of
sudo su. Or on Debian just use su without the - argument. sudo was
explicitly configured to not scrub DISPLAY so that users can still run
X11 applications after sudoing, but has not been updated to include
WAYLAND_DISPLAY in that list. You can also of course, simply set
WAYLAND_DISPLAY after sudoing to root.

> Therefore, I'm closing this bug. Sorry.

I'm sorry, but as long as the man page for gdm says that it will
configure an XAUTHORITY and it does not, this is ipso facto, a bug,
whatever you think about gui applications running as root.

If this really was an intentional change upstream, they should document
it in the NEWS and man page. I certainly have not been able to find
anything in the changelog or git commit history that indicates this was
intentional, and of course, the man page should be updated to match the
new implementation if it was intended.

[Jeremy Bícha (jbicha)]

It has been widely publicized at least since Fedora 25's release a year ago that GNOME on Wayland does not support running GUI apps as root. It has long been best practice for apps to not do this. Instead of trying to implement clever workarounds, app developers should follow best practice here.

Would you like to submit a patch for sudo? The GDM maintainer Ray Strode rightfully believes that it is wrong (i.e. Won't Fix) to have XWayland support running apps as root as long as Wayland does not. Therefore, someone will need to have a proposed fix for that issue first before worrying about XWayland.

At this point, I don't believe that Ubuntu intends to diverge from upstream on this issue, so to some extent, Won't Fix is appropriate here too. So fix things upstream instead of complaining to Debian and Ubuntu.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[John Runyon (dimecadmiu)]

How is not properly setting up the session, and preventing root from showing things on the display, "for security"?

root, by definition, has the ability to do anything anywhere on the system. Including reading and writing other users' files; reading and writing the memory of processes (and FD's and environment and ...) from other users, etc. Adding extra steps is not security, it's just making things more difficult for users.

[Jan Claeys (janc)]

Because a non-root program can then use X11 to make that root program do things you don't want.

[Wise Melon (wise-melon-deactivatedaccount)]

The official upstream GNOME bug has been moved to here: https://gitlab.gnome.org/GNOME/gdm/issues/342

[Jeremy Bícha (jbicha)]

I updated the bug description to point to how openSUSE handles this bug and opened a mutter task in case we want to copy it.

[Phillip Susi (psusi)]

Ubuntu doesn't use mutter by default though ( is that what lubuntu uses? ). I looked at this again today and for some reason gdm isn't giving the option to log in with a wayland session. I switched to lightdm and it appears to not bother with Xwayland and just runs gnome-shell, and gnome-shell in turn spawns Xwayland, so *it* needs patched to add XAUTHORITY too.

[Daniel van Vugt (vanvugt)]

Phillip,

Mutter is not just a binary, but is also the library which provides ALL the graphics for the login screen and gnome-shell. So yes Ubuntu does use mutter for everything :)

If your Wayland login option has gone missing then that means the Wayland backend ("eglnative") of mutter had crashed during startup and so has been disabled. Please log a NEW bug for that by running:

  ubuntu-bug gnome-shell

on the machine.

[Phillip Susi (psusi)]

On 8/21/2018 9:34 PM, Daniel van Vugt wrote:
> Phillip,
>
> Mutter is not just a binary, but is also the library which provides ALL
> the graphics for the login screen and gnome-shell. So yes Ubuntu does
> use mutter for everything :)

Ohh... I thought it was an alternative light weight compositing window
manager similar to compiz. Or was that clutter?

I'm not sure why taking care of spawning Xwayland would be in the
compositing graphics library.

> If your Wayland login option has gone missing then that means the
> Wayland backend ("eglnative") of mutter had crashed during startup and
> so has been disabled. Please log a NEW bug for that by running:

Will do. Happens in a virtual machine so should be easy to reproduce.

[Daniel van Vugt (vanvugt)]

I'm only recently familiar with the Mutter design, but...

Mutter is the graphics platform on which gnome-shell is built. Mutter supports running under a Xorg server, or none at all on bare metal (Wayland mode). So in order to provide a seamless consistent interface in the latter case it spawns Xwayland, which allows X apps to work with Wayland even when Mutter's not running on Xorg. In this way, any shell built on Mutter has the option to use Xorg or Wayland, and if using Wayland can still transparently run X apps.

"Clutter" is the graphics toolkit on which Mutter is built. "Cogl" is the graphics toolkit on which Clutter is built. Cogl uses OpenGL directly. Yes, that's probably too many layers but that's how things evolved.

[Daniel van Vugt (vanvugt)]

Sounds like a fix is on the way:

https://gitlab.gnome.org/GNOME/mutter/merge_requests/626