You are not logged in.
Currently, for many graphical applications that require root privileges (ie gparted or grub-customizer,) when you try to open them in Wayland, the gtk widget fails with the error Gtk-WARNING **: cannot open display: :0, Basically this boils down to Wayland not allowing processes to run as a different user.
Now, a work-around is to allow root to run applications on my desktop by running the following:
xhost +SI:localuser:rootIs there any reason, (security related or otherwise,) why I shouldn't run this at startup?
Irvine
Last edited by IrvineHimself (2019-06-14 08:45:50)
Et voilà, elle arrive. La pièce, le sous, peut-être qu'il arrive avec vous!
Offline
Sorry, apparently it only needs to be run once. The reference implies it needs to be run once each session before running a GUI as root:
Allow root to display applications on your desktop. Before running GParted type the following into a terminal window:
However, after powering down to take care of other business, I can still run graphical applications as root, without running xhost
Sorry for the bother,
A very embarrassed Irvine
Et voilà, elle arrive. La pièce, le sous, peut-être qu'il arrive avec vous!
Offline
I think xhost shouldn't be permanent. I don't know where exactly it saves its state, maybe something was left from previous session?
In general I recommend reading Arch wiki first rather than 3rd part sources, XAUTHORITY approach is considered safer than xhost:
https://wiki.archlinux.org/index.php/Ru … te_methods
Offline
Thank you for that.
I agree completely with what you say about the arch Wiki always being the first port of call, and generally either search the Wiki directly from my search bar, or, alternatively, preface a google search with Arch. However, in this case, I was searching for what I thought was a bug and ended up at the Red hat Bugzilla report I linked to above, which, incidentally, is also the same bug report referenced in the Wiki. From there, I just naively followed the links to the reported solution.
Your comment has given me a lot to think about. For most stuff I do as root, I don't have a problem with using nano or the terminal instead of my text-editor and file-manager, but gparted and grub-customizer are just far to practical to do without.
My first thought was a wrapper called, for example, called gparted, in /usr/local/bin:
#!/bin/bash
xhost si:localuser:root
/usr/bin/gparted
xhost -si:localuser:rootHowever, even after after a reboot, xhost -si:localuser:root wasn't removing root from the access control list. Additionally, xhost doesn't require any special privileges, hence leaving it on my system would create an ongoing potential vulnerability. As a result, I think the best solution is to leave xorg-xhost in the pacman-cache but only have it actually installed on an as-needed basis.
When one follows the reference links of the Wiki article you mentioned, there are some fascinating debates on this whole topic. Noting that, despite my initial assumption, the original problem was not actually a bug, but an essential part of the Wayland security model: There is a quote which resonated deeply
The point is that [lists of applications which can run as root/other-users] are 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.
So, despite the many complications from ditching the Xorg-server, of which this particular problem is only an example, I still think wide scale adoption of Wayland is the way forward. For me, as a user, it requires a new way of thinking about things, and, by extension, the same is true for software developers. Ultimately, if they wish people to continue to use their software, then they are going to have to adapt to the new world order.
A comparable example is the recent changes to the extension API in Firefox, which, along with related changes to policy, generated howls of protest. At the end of the day however, the add-ons I find most useful are still there and I have more a secure browser as a result.
Irvine
Et voilà, elle arrive. La pièce, le sous, peut-être qu'il arrive avec vous!
Offline