pkexec on Wayland

johnraff · 2024-08-23 07:21:31

TL:DR go to the bottom of the post.

Pkexec is already enough trouble - it won't work unless "policy" files are configured in /usr/share/polkit-1/actions for the things you want to be able to open as root. Then to modify any other app's policy you need to make "rules" files instead of the (slightly) simpler pkla we used to have. (The good news is BL doesn't ship many pkla rules.)

Basically, running GUI apps as root is unsafe and the über-devs are making it as difficult as possible for us, for our own good I guess. But how are you going to use gparted without root? Synaptic roo. Until the upstream developers rewrite them from the bottom up to separate out the GUI part from the bits that need root, we have to manage somehow...

But all that aside, if you've been playing with Wayland you might have noticed that pkexec doesn't work at all.

https://forums.bunsenlabs.org/viewtopic … 98#p132898

hhh wrote:

Things I didn't solve before removing labwc...
~ get pkexec to work (I had to force nautilus into admin mode with 'sudo -E nautilus')

https://forums.bunsenlabs.org/viewtopic … 22#p135822

hhh wrote:

# Example autostart file
xhost +SI:localuser:root > /dev/null 2>1 &
xhost is to get gparted and other GUI apps that need root permission to run. This is not recommended on a multi-user machine, but it's the most practical way I've found to get a normal setup where everything works.

@hhh isn't the only one to have hit issues with launching GUI apps as root on Wayland:
https://bugs.debian.org/cgi-bin/bugrepo … bug=880601
https://bugs.debian.org/cgi-bin/bugrepo … bug=883812
and many others if you search.

There do seem to be workarounds though.

1) Run xhost at the start of a session. That does look a bit scary to be honest, though maybe OK for @hhh's testbench install.

2) Slightly (?) better: switch on xhost just before running the app, then close it when the app has exited - in a wrapper script?

xhost +si:localuser:root
<application>
xhost -si:localuser:root

https://wiki.archlinux.org/title/Runnin … sing_xhost

3) Sudo has an -E option to pass the caller's environment variables to root, which lets it work on Wayland. Add the -H option so HOME is set to /root instead of /home/<user> and it looks as if it might be sort of OK:

sudo -EH <application>

That opens apps like synaptic, gparted or bl-text-editor as root on Wayland. The main annoyance is that you need an open terminal to run it, so menu items are a bit clunky.

4) Pkexec is deliberately made not to pass on environment variables to the target (security, right) so there's no option like -E, but... finally I found a bit of hope. You can specifically pass along certain environment variables in the pkexec command, and they get picked up and at least for some applications, they will run as root on Wayland.
In a Wayland session, first confirm that this does not work:

pkexec thunar /etc

Now try this:

pkexec env WAYLAND_DISPLAY="$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY" XDG_RUNTIME_DIR=/run/user/0 thunar /etc

OK yes?
https://github.com/mvo5/synaptic/issues … 1183357803
https://unix.stackexchange.com/a/709811/189202

That could be a way forward if we make a little wrapper script around pkexec and call it in a few select cases that we want to work, that don't right now.

Is it safe? It looks to me - for whatever that's worth - as if it might be safer than xhost, and maybe a bit safer than 'sudo -EH' which is passing on the whole environment, not just WAYLAND_DISPLAY and XDG_RUNTIME_DIR.

Not all apps need this. Some things - like galternatives - have already got it sorted, so we'd only need to use it in a few cases, in the BL menu, launchers, and a couple of edited .desktop files.

feedback welcome

DeepDayze · 2024-08-23 13:11:23

This might be a good workaround until more apps become Wayland-aware, and pkexec (and any other security related app) needs to also become Wayland aware to function properly on native Wayland. Perhaps through bug reports the pkexec upstream devs would consider adding Wayland support to pkexec.

PackRat · 2024-08-23 13:57:21

DeepDayze wrote:

This might be a good workaround until more apps become Wayland-aware, and pkexec (and any other security related app) needs to also become Wayland aware to function properly on native Wayland. Perhaps through bug reports the pkexec upstream devs would consider adding Wayland support to pkexec.

That probably isn't going to happen. Not running GUI as root is a [safety] feature of Wayland, not a bug. From the linked bug report thread above:

Wayland is designed to be per-uid. If you want X11, I would suggest
using X11.
Running GUIs as root gives them a huge attack surface, breaking the
privilege separation between root and the user that owns the display.
It has historically worked, but that doesn't make it a good idea for the
future (or the present, for that matter). The move from X11 to Wayland,
at which traditional approaches to various things (e.g. screenshots) break
anyway due to Wayland having the concept of privileged and unprivileged
clients, is a convenient flag-day to move from "discouraged but still
works" to "a line has been drawn here, this no longer works".

The simplest workaround is to open a terminal, su to root, and then start the program from the terminal. Although, that requires a root password and the trend is for distros to not to set one up during install.

@johnraff - in regards to this:

That could be a way forward if we make a little wrapper script around pkexec and call it in a few select cases that we want to work, that don't right now.

Rather than having a "few select cases" - which I'm interpreting as several wrapper scripts - could you also go with one yad (bash, python, perl ...) script that sets the environment then allows the user to select the application to be run as root from a list?

DeepDayze · 2024-08-23 14:11:13

PackRat wrote:

Rather than having a "few select cases" - which I'm interpreting as several wrapper scripts - could you also go with one yad (bash, python, perl ...) script that sets the environment then allows the user to select the application to be run as root from a list?

That makes sense.

Last edited by DeepDayze (2024-08-23 14:11:36)

Sector11 · 2024-08-23 14:27:14

This is what I do not understand.

All of a sudden people are telling us it is unsafe to run GUI programs with root privileges and taking that away from from us. They are locking down Linux like Windows.
"You will do it the way 'we' want."

FOO FOO to you.

A long time ago, a friend who walked around with his head on a stick gave me a nice little command

sudo -H sh -c thunar

that also works in an open box menu like this:

<execute>terminator --geometry=350x25+30+30 -x sudo -H sh -c thunar</execute>

Will it work in "OurWayLand"? → probably not.

But it's good enough for me for now.

unklar · 2024-08-23 14:38:50

DeepDayze wrote:

This might be a good workaround until more apps become Wayland-aware, and pkexec (and any other security related app) needs to also become Wayland aware to function properly on native Wayland. Perhaps through bug reports the pkexec upstream devs would consider adding Wayland support to pkexec.

^under (X)Wayland this does not work anymore as the default has been made to only allow the user who started the X server to connect clients to it.
https://wiki.archlinux.org/title/Runnin … ot#Wayland

In fact, I only know the variants already mentioned here by @hhh

-->xhost
-->sudo -E (EH)

Another hack would be an entry in the 'environment' of labwc the variable

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gparted

source

However, I have not tested this myself because there was no need.

PackRat wrote:

Rather than having a "few select cases" - which I'm interpreting as several wrapper scripts - could you also go with one yad (bash, python, perl ...) script that sets the environment then allows the user to select the application to be run as root from a list?

So, @PackRat's suggestion could be practicable.

PackRat · 2024-08-23 15:40:41

Sector11 wrote:

All of a sudden people are telling us it is unsafe to run GUI programs with root privileges and taking that away from from us. They are locking down Linux like Windows.
"You will do it the way 'we' want."

People have been saying for years that running GUI with root privileges is a safety risk, bit it was a warning and users could make their own decisions. Now with Wayland it won't be allowed. In one regard it's worse that Windows because Windows does have the "run as" option on the menu which is similar to pkexec. I'm sure there will be some 3rd-party scripts/programs for Wayland that will perform the function of pkexec, but since that violates the design philosophy of Wayland, odds are it will not be included in the package repos for a distro, like Debian, that adopts Wayland.

And I checked; your command to launch thunar with root privileges does fail on Wayland.

unklar · 2024-08-23 17:40:37

PackRat wrote:

And I checked; your command to launch thunar with root privileges does fail on Wayland.

^ I do, but I don't know why.
xwayland ?

With sway, where only wayland is running, it doesn't work.

johnraff · 2024-08-24 05:06:29

This is tricky stuff and some of you good people have likely got a better grip on some of it than me, but FWIW this is how I understand the situation:

Yes running a GUI as root has always been dangerous, but we've been doing it anyway:

maybe once in a while to run eg gparted or synaptic
Some people regularly run GUI text editors as root. (Yes I quite often run geany as root. For small edits it's easy enough to run 'sudo nano file' but geany makes it easier for sure.)
Some people log into a whole graphical session as root.

So there are degrees of danger. My car beeps a warning if I don't fasten my seatbelt before backing into the garage.

I think pkexec is itself a workaround, and will likely go away eventually. I hope by then the gparted and synaptic developers have rewritten the apps so that the GUI runs as a regular user and root is only used where it's actually needed - GDebi and galternatives already do this. (Gparted might be difficult though.)

To see which windows are using xwayland, install x11-apps and run 'xeyes'. The eyes don't move except when the cursor is over an xwayland window, when the eyes follow the cursor.

This works to launch thunar in Wayland:

sudo -EH thunar

And according to xeyes, it's not using xwayland.
The pkexec line I posted works too:

pkexec env WAYLAND_DISPLAY="$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY" XDG_RUNTIME_DIR=/run/user/0 thunar

Also not using xwayland. A difference between those two is that the second one opens in the /root directory, the first one in /home/john. I think the sudo -E option is passing all my environment over to the root command, while in the second one it's only the WAYLAND_DISPLAY, which feels a bit safer.

Another thing with pkexec is that it pops up a window for the password, so doesn't need to be run from a terminal. You can launch it from a menu. I put that command in a little script called 'thunar-env' and you can call thunar-env from eg gmrun.

So thunar is able to run natively on Wayland. So are eg gparted, synaptic, lxterminal and geany ( now in Trixie ).

What now needs testing is how to pkexec an app which needs xwayland to run. The above code aborts out with "can't open display :0" if I try to run urxvt (which does get the moving eyes). Same with 'sudo -EH urxvt'. Maybe there are a couple of X variables to pass to make pkexec work on xwayland...

PackRat wrote:

The simplest workaround is to open a terminal, su to root, and then start the program from the terminal. Although, that requires a root password and the trend is for distros to not to set one up during install.

If you've got a terminal open, and the program works on Wayland, then 'sudo -EH <program>' seems to work, or the longer (and possibly safer) pkexc command.

@johnraff - in regards to this:
That could be a way forward if we make a little wrapper script around pkexec and call it in a few select cases that we want to work, that don't right now.
Rather than having a "few select cases" - which I'm interpreting as several wrapper scripts...

I meant having one small script called eg 'pkexec-env' which people could use instead of pkexec to run a wayland-capable app as root, in Wayland. "Select cases" meant that our menu would have eg 'pkexec-env bl-text-editor <configfile' in a few places, likewise some .desktop files and the like. Of course users could then run 'pkexec-env <app>' on anything they liked. (Though they might get stopped by polkit if their app isn't registered.)

- could you also go with one yad (bash, python, perl ...) script that sets the environment then allows the user to select the application to be run as root from a list?

That should work too, and a fixed list would be a bit safer. Another convenience/safety tradeoff.

unklar wrote:

In fact, I only know the variants already mentioned here by @hhh
-->xhost
-->sudo -E (EH)

You didn't try the pkexec command I posted above?

pkexec env WAYLAND_DISPLAY="$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY" XDG_RUNTIME_DIR=/run/user/0 thunar

That works, on Wayland for wayland-capable apps.

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gparted

This didn't work for me.

I'll see if I can dig up a command that works for xwayland apps...

micko01 · 2024-08-24 06:45:25

Found this on Fedora forum and tried it:

sudo --preserve-env=XDG_RUNTIME_DIR,WAYLAND_DISPLAY /usr/sbin/gparted

Going to see if I can format a USB stick with it.

---------

Later..

Yes! It works

Last edited by micko01 (2024-08-24 07:30:39)

johnraff · 2024-08-24 07:38:49

^Isn't that pretty much the same as 'sudo -EH gparted'?
And very likely the pkexec version too - they're all passing WAYLAND_DISPLAY to the root process, and it's working with native wayland apps on a Wayland system. All the stuff you read, though, makes it sound as if it's not supposed to work.

micko01 · 2024-08-24 08:16:26

^pkexec version failed. It's also probably of no use trying to do it via Xwayland, another layer of complexity and there a folk getting DISPLAY errors everywhere.

Yeah sudo -EH works just as well. Took only a few seconds to re-format that same USB stick to FAT32 and back to ext4.

unklar · 2024-08-24 08:46:21

johnraff wrote:

You didn't try the pkexec command I posted above?
pkexec env WAYLAND_DISPLAY="$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY" XDG_RUNTIME_DIR=/run/user/0 thunar

that works.

In contrast, @micko01 variant does not work here.

micko01 wrote:

^pkexec version failed. It's also probably of no use trying to do it via Xwayland, another layer of complexity and there a folk getting DISPLAY errors everywhere.

(gpartedbin:32041): Gtk-WARNING **: 10:27:04.376: cannot open display: :0

Sector11 · 2024-08-25 01:08:17

UNREAL

And yes you are right PackRat, there was always the warning.
BUT I was allowed to make the choice on MY computer.

Linux is turning into iOS, Windows and Android where freedom of choice is: Do it our way.
{OK /rant}

johnraff · 2024-08-25 01:28:39

^I think there will always be workarounds. For now, for example if you're on Wayland and want to launch a Wayland app, this seems to work:

sudo -EH <app>

Probably no more dangerous that what you've been doing up to now.

Launching an X11-only app on Wayland via xwayland, as root, is one we haven't found a workaround for yet. But in practice, how many apps are there left that you still would want to launch that way?

If anyone has a favourite app they need to be able to launch as root via xwayland, could they post the name? People here might find a workaround...

For me, GUI-as-root comes down to quite a short list: gparted (the biggie IMO), synaptic, a text editor, a file manager... any others? All those apps are native Wayland now and should be launchable with one of those pkexec or sudo commands.

Others like GDebi and galternatives have already moved to a safer structure where the GUI doesn't need to be run as root anyway. Hopefully some day they'll all do that and the problem will go away.

johnraff · 2024-08-25 01:41:52

micko01 wrote:

^pkexec version failed.

For me, gparted opened a window when launched with the pkexec command. The xeyes test confirmed it's not using xwayland.

But I didn't actually try to use it to make any changes to my drives, because I was on a VM and it looked tricky, likewise trying to format an external drive (though that should in fact be possible via qemu).

@micko01 in what way did the pkexec command fail for you? Did it fail to even open a window, or fail to do the task you gave it? Have you got the polkit packages installed that support pkexec?

It's also probably of no use trying to do it via Xwayland, another layer of complexity and there a folk getting DISPLAY errors everywhere.

I'm not sure what "trying to do it via xwayland" would actually mean. Doesn't the system itself decide whether to invoke xwayland or not, based on whether the app being launched supports Wayland directly?

Urxvt is one example of a non-wayland app that uses xwayland, and I found it could not be launched by any of the above commands that work on native Wayland apps.

johnraff · 2024-08-25 01:44:32

unklar wrote:

johnraff wrote:
...the pkexec command I posted above?
that works.
In contrast, @micko01 variant does not work here.

That's interesting. On my Wayland VM both commands worked:

pkexec env WAYLAND_DISPLAY="$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY" XDG_RUNTIME_DIR=/run/user/0 gparted

sudo --preserve-env=XDG_RUNTIME_DIR,WAYLAND_DISPLAY /usr/sbin/gparted

johnraff · 2024-08-25 04:47:21

johnraff wrote:

micko01 wrote:
^pkexec version failed.
For me, gparted opened a window when launched with the pkexec command.
gparted
But I didn't actually try to use it to make any changes to my drives...

I just tested again and with both that pkexec command and with the 'sudo --preserve-env...' command I was able to resize the swap partition. Both work, and the messages left in the terminal are identical.

pkexec env WAYLAND_DISPLAY="$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY" XDG_RUNTIME_DIR=/run/user/0 gparted

NOTE: the last part:

XDG_RUNTIME_DIR=/run/user/0

is needed for the command to work, but it needn't point to a real directory, it can be set to anything eg 'XDG_RUNTIME_DIR=dummy'. So the library wants that directory to be set, but doesn't actually try to write anything there. This looks like a bug to be honest, and if it's fixed then the command might have to be changed, or even stop working...

johnraff · 2024-08-25 05:21:24

check the environment

'env' with no arguments prints out the current environment, so it's interesting to launch it all the various different ways we've been testing, to see how the environment passed to the app changes. In a Wayland session, things like:

env
sudo env
sudo -EH env
sudo --preserve-env=XDG_RUNTIME_DIR,WAYLAND_DISPLAY env
pkexec env
pkexec env WAYLAND_DISPLAY="$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY" XDG_RUNTIME_DIR=/run/user/0 env

It's quite hard to see the differences, so you can write it to files and then run diff on the files, eg:

sudo -EH env > sudoeh
pkexec env WAYLAND_DISPLAY="$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY" XDG_RUNTIME_DIR=/run/user/0 env > pkexecwd
diff sudoeh pkexecwd

Try all the combinations and see which commands pass the smallest environment. Which ones don't send on eg your Debian email address or add ~/bin to PATH...

micko01 · 2024-08-25 06:21:48

^ turns out your pkexec line is fine for me. I found the culprit, my USB HDD is going bad, and gparted was taking forever to scan so I though 'failure'. Later, when I unplugged and put in the USB stick all was ok with 'sudo -EH' line, didn't think to ty try pkexec.

Anyway, just tried pkexec with the stick and it works the same as with 'sudo -EH'. Just formatted to FAT32 and back to ext4 in a matter of seconds.

Plugged USB HDD into another machine and errors can't be fixed. Oh well, it's backed up so no loss.

Now to replace that USB HDD

#1 2024-08-23 07:21:31

pkexec on Wayland

#2 2024-08-23 13:11:23

Re: pkexec on Wayland

#3 2024-08-23 13:57:21

Re: pkexec on Wayland

#4 2024-08-23 14:11:13

Re: pkexec on Wayland

#5 2024-08-23 14:27:14

Re: pkexec on Wayland

#6 2024-08-23 14:38:50

Re: pkexec on Wayland

#7 2024-08-23 15:40:41

Re: pkexec on Wayland

#8 2024-08-23 17:40:37

Re: pkexec on Wayland

#9 2024-08-24 05:06:29

Re: pkexec on Wayland

#10 2024-08-24 06:45:25

Re: pkexec on Wayland

#11 2024-08-24 07:38:49

Re: pkexec on Wayland

#12 2024-08-24 08:16:26

Re: pkexec on Wayland

#13 2024-08-24 08:46:21

Re: pkexec on Wayland

#14 2024-08-25 01:08:17

Re: pkexec on Wayland

#15 2024-08-25 01:28:39

Re: pkexec on Wayland

#16 2024-08-25 01:41:52

Re: pkexec on Wayland

#17 2024-08-25 01:44:32

Re: pkexec on Wayland

#18 2024-08-25 04:47:21

Re: pkexec on Wayland

#19 2024-08-25 05:21:24

Re: pkexec on Wayland

#20 2024-08-25 06:21:48

Re: pkexec on Wayland

Board footer