pkexec on Wayland

johnraff · 2024-08-25 06:39:49

So it looks as if we've got a workaround for menu items that used to call 'pkexec bl-text-editor' and the like. Just need to make a little wrapper script (eg "pkexec-env") that tests for a Wayland session and uses the pkexec+environment command if so, and uses plain pkexec as before if on X11, then call that script instead of pkexec.

pkexec-env <appname>

The only thing it won't work for is if someone wants to run an X11 (no Wayland support) app on Wayland, via xwayland, as root. Right now I can't think of anything that would fall in that group. Fingers crossed...

Bearded_Blunder · 2024-08-25 09:21:32

johnraff wrote:

The only thing it won't work for is if someone wants to run an X11 (no Wayland support) app on Wayland, via xwayland, as root. Right now I can't think of anything that would fall in that group.

I can think of something that may fall into that category, but it's one of those things you'd just take a different approach to if so, not a big deal or deal-breaker. Problem being I've been too snowed under to do any testing.

The culprit would be VirtualBox, which in the very specific instance you need to assign a physical drive to a VM requires it to be run as root (same would apply to VMWare, & probably QEMU if giving them a physical drive, I'm unsure of the status of those WRT Wayland though, haven't looked up if you even can assign a physical drive with QEMU).

However, that's a VERY niché use case even though I sometimes run into it, only really arises for a Linux host if for some reason you need to run manufacturer specific DOS/Windows software against a drive for purposes of e.g. raising an RMA, & I really don't think it's one to worry about.

I'll doubtless attempt it at some future date, but it won't be soon unless the specific scenario arises where I need to, I haven't the spare time to be trying that "pour le sport".

johnraff · 2024-08-25 09:36:52

^Niche maybe, but important for those in that situation.
I haven't yet looked at Wayland support for virt-manager & qemu, although the way mine's configured it doesn't need root anyway.
VirtualBox, sorry no idea, though it's big enough that people will presumably be agitating for a fix on the Fedora forums if there isn't one yet...

Bearded_Blunder · 2024-08-25 09:51:33

Currently the VM I use for passing physical drives is on a Windows host, & thus requires running as Admin, been a while since I did such a thing with a Linux host & had to run the VM as root (think I was on Jessie) back then VMWare worked better than VBox for it anyhow, though both worked. Possibly the same may also arise passing through other hardware directly to a VM, such as a video card, I know it does for drives though.

I've yet to set up any sort of Wayland test-bed, even inside a VM, much less one with a Wayland host. Hopefully life will calm down enough before too long.. fingers crossed.

Sector11 · 2024-08-26 03:06:03

micko01 wrote:

Now to replace that USB HDD

Curious - How long ± do those things last?

micko01 · 2024-08-26 03:37:11

Sector11 wrote:

micko01 wrote:
Now to replace that USB HDD
Curious - How long ± do those things last?

I've had this one 9 years, mostly plugged in.

Edit to add:

My chihuahua chewed the cable when he was a pup. He's 9 now. Could be only the cable that is flakey.

Last edited by micko01 (2024-08-26 08:26:20)

DeepDayze · 2024-08-26 11:59:26

micko01 wrote:

Sector11 wrote:
micko01 wrote:
Now to replace that USB HDD
Curious - How long ± do those things last?
I've had this one 9 years, mostly plugged in.
Edit to add:
My chihuahua chewed the cable when he was a pup. He's 9 now. Could be only the cable that is flakey.

Try swapping the cable for a new one and maybe you might be able to resurrect the drive. But at 9 years old it may be time to consider replacing it soon anyhow.

Sector11 · 2024-08-26 16:44:49

9 years with a chewed cable.
A Miracle!

That thing belongs under glass on a mantel someplace!

johnraff · 2024-08-27 05:24:15

So if you're tired of the "open as root" menu items in thunar not working on wayland, here's a quick fix. Make a file called pkexec in ~/bin with this content:

#!/bin/sh

if [ -n "$WAYLAND_DISPLAY" ]
then
    /usr/bin/pkexec env WAYLAND_DISPLAY="$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY" XDG_RUNTIME_DIR=/run/user/0 "$@"
else
    /usr/bin/pkexec "$@"
fi

( The full path to /usr/bin/pkexec is needed to stop the script from recursively calling itself. )
Make sure ~/bin/pkexec is executable and ~/bin is in your $PATH.

Then pkexec will be overridden by this script anywhere it's called, and all those "...as root" things should work again.
I think it would be a bit rude to ship something like that as standard in BL because users might not realize they are running a non-standard pkexec, but for devs and testers it's fine IMO.

micko01 · 2024-11-07 13:09:49

I've been think about this lately - can we package the pkexec wrapper script in bunsen-configs in /skel? Otherwise we need to rename it I think.

Also gparted comes with a broken .desktop file for wayland becuase, and I quote from the script then the debian salsa repo https://salsa.debian.org/debian/gparted … type=heads

if test "x`id -u`" != "x0"; then
	#
	#  If there is no configured SU program run gpartedbin as
	#  non-root to display the graphical error about needing root
	#  privileges.
	#
	if test "xpkexec --disable-internal-agent" = "x"; then
		echo "Root privileges are required for running gparted."
		$BASE_CMD
		exit 1
	fi

	#
	# Interim workaround to allow GParted run by root access to the
	# X11 display server under Wayland.  If configured with
	# './configure --enable-xhost-root', the xhost command is
	# available and root has not been granted access to the X11
	# display via xhost, then grant access.
	#
	ENABLE_XHOST_ROOT=no
	GRANTED_XHOST_ROOT=no
	if test "x$ENABLE_XHOST_ROOT" = 'xyes' && xhost 1> /dev/null 2>&1; then
		if ! xhost | grep -qi 'SI:localuser:root$'; then
			xhost +SI:localuser:root
			GRANTED_XHOST_ROOT=yes
		fi
	fi

	#
	# Run gparted as root.
	#
	pkexec --disable-internal-agent '/usr/sbin/gparted' "$@"
	status=$?

	#
	# Revoke root access to the X11 display, only if we granted it.
	#
	if test "x$GRANTED_XHOST_ROOT" = 'xyes'; then
		xhost -SI:localuser:root
	fi
	exit $status
fi

Now that code might be ok if './configure --enable-xhost-root' is enable but (from debian salsa debian/rules)

override_dh_auto_configure:
	dh_auto_configure -- --enable-libparted-dmraid --bindir=\$${prefix}/sbin

.. and that's it for configure args (apart from the defaults that dh sets)

We could possibly point the .desktop file to a modified version 'Bunsen GParted' (or something in .local/share/applications) and point that at our wrapper. Should work (with a bit more creativity):

Exec=/home/user/bin/pkexec /usr/sbin/gparted %f

johnraff · 2024-11-08 04:40:48

micko01 wrote:

I've been think about this lately - can we package the pkexec wrapper script in bunsen-configs in /skel? Otherwise we need to rename it I think.

Yes renaming is what I had in mind.

johnraff wrote:

I think it would be a bit rude to ship something like that as standard in BL because users might not realize they are running a non-standard pkexec...

If we ship it as eg pkexec-env then we'll need to rewire our menu items and desktop files to call that instead of straight pkexec. A bit of extra work for us, but perhaps less confusing for users.

Also gparted comes with a broken .desktop file for wayland...

In fact, the code's not in the desktop file, but in /usr/sbin/gparted, but anyway clearly broken regardless of session type.

This test makes no sense:

if test "xpkexec --disable-internal-agent" = "x"; then

...it will always fail.
Perhaps they wanted to test if an external agent like lxpolkit was available - maybe they intended something like:

if test "x$( pkexec --disable-internal-agent )" = "x"; then

but I'm not at all sure that would work correctly either.

Now that code might be ok if './configure --enable-xhost-root' is enable but...

Luckily there seems to be a way out of this without getting involved in the xhost security controversy.
The same pkexec-env script can be used to run gparted too:

pkexec-env gparted

I just ran this in a Wayland VM and gparted came up. I didn't actually try to resize my swap partition or anything, but it looks OK. So if we edit our menus to use pkexec-env, and override gparted.desktop with a file in ~/.local/share/applications/ that should be enough to be going on with?

That broken test can be ignored IMO because we will be shipping a "SU program", probably lxpolkit, so the graphical error message won't be used.

micko01 · 2024-11-08 07:46:13

johnraff wrote:

Yes renaming is what I had in mind.

Yeah thought so.

johnraff wrote:

I think it would be a bit rude to ship something like that as standard in BL because users might not realize they are running a non-standard pkexec...
If we ship it as eg pkexec-env then we'll need to rewire our menu items and desktop files to call that instead of straight pkexec. A bit of extra work for us, but perhaps less confusing for users.
Also gparted comes with a broken .desktop file for wayland...
In fact, the code's not in the desktop file, but in /usr/sbin/gparted, but anyway clearly broken regardless of session type.

Well it's broken because it fails. I realise it's down the chain where it fails but GParted is a Gnome application and since they are pushing wayland they should fix it! . LXpolkit should be fixed too because the password GUI runs as Xwayland. Good for nothing in a pure wayland setup.

This test makes no sense:
if test "xpkexec --disable-internal-agent" = "x"; then
...it will always fail.
Perhaps they wanted to test if an external agent like lxpolkit was available - maybe they intended something like:
if test "x$( pkexec --disable-internal-agent )" = "x"; then
but I'm not at all sure that would work correctly either.

The first test is an absolute waste of bytes! I've seen your idea applied in other scripts and while it seems to work I'm not a fan of that syntax.

The same pkexec-env script can be used to run gparted too:
pkexec-env gparted
I just ran this in a Wayland VM and gparted came up. I didn't actually try to resize my swap partition or anything, but it looks OK. So if we edit our menus to use pkexec-env, and override gparted.desktop with a file in ~/.local/share/applications/ that should be enough to be going on with?
That broken test can be ignored IMO because we will be shipping a "SU program", probably lxpolkit, so the graphical error message won't be used.

Yes it works fine and I can even demonstrate it working for a bogus menu entry! I copied gparted.desktop to .local/share/applications and edited the Name= and Exec= lines

Name=GParted FOO
Exec=pkexec.wrap /usr/sbin/gparted %f

(you see I renamed your script)

type pkexec.wrap
pkexec.wrap is /home/mick/bin/pkexec.wrap

Works perfectly! Obviously 2 menu entries though, but we could survive with that if the name is sensible.

johnraff · 2024-11-08 08:21:14

micko01 wrote:

The same pkexec-env script can be used to run gparted too:
pkexec-env gparted
Yes it works fine and I can even demonstrate it working for a bogus menu entry! I copied gparted.desktop to .local/share/applications and edited the Name= and Exec= lines
Name=GParted FOO
Exec=pkexec.wrap /usr/sbin/gparted %f
(you see I renamed your script)
type pkexec.wrap
pkexec.wrap is /home/mick/bin/pkexec.wrap
Works perfectly! Obviously 2 menu entries though, but we could survive with that if the name is sensible.

Just leave the filename and Name unchanged and it will override the system file and there'll be only one menu entry.
(See bunsen-configs skel/.local/share/applications/gdebi.desktop)

pkexec.wrap is a nice name - I'd be quite happy with that. We can put it in /usr/bin no problem.
...or possibly pkexec.wrapper to match gdebi-gtk.wrapper

Last edited by johnraff (2024-11-08 08:23:03)

micko01 · 2024-11-08 08:33:36

johnraff wrote:

Just leave the filename and Name unchanged and it will override the system file and there'll be only one menu entry.

Works a charm.

Thanks

trinidad · 2025-05-21 16:13:15

Digging this up again, because you call sudo -E or sudo -EH it's easier to create a sudoers.d file and run the application from the terminal.

Run: sudo echo 'Defaults env_keep += "XDG_RUNTIME_DIR"
Defaults env_keep += "WAYLAND_DISPLAY"' | sudo tee /etc/sudoers.d/wayland

This creates an /etc/sudoers.d file that keeps the wayland env. Allows me to to use anything in the terminal with: sudo (whatever application). Thunar only throws thumbnail errors but opens as root. Several others work without errors. Of course I was counseled not to do this by a few "experts" and a terminal warning not to do it. Kinda funny to me. Works on XFCE 4.20 too. I've run wayland since Debian Jessie and in fact the whole focus on security as a selling point misses the real potential of wayland and systemd: clearly defined modularity, and a future of less code not more. There's so much potential it's sad to me the way this has all rolled out.

TC

Head_on_a_Stick · 2025-05-21 16:55:42

There doesn't seem to be a problem with running gparted under Wayland for Debian bookworm:

And thunar now supports the GVFS admin:// backend to allow for root access to the filesystem:

https://wiki.archlinux.org/title/Runnin … _root#GVFS

For the text editor I think this approach is better:

SUDO_EDITOR=bl-text-editor sudoedit $file

BunsenLabs uses sudo anyway so why not utilise sudoedit to make editing root files less risky?

And finally for the "root terminal":

x-terminal-emulator -e sudo -i

^ That way just the shell gets elevated privileges, not the entire GUI. See also https://git.sr.ht/~head_on_a_stick/dead … al.desktop.

Sector11 · 2025-05-21 23:17:37

trinidad wrote:

{snip} or sudo -EH {snip}

That's the Canadian "sudo eh!"

Sorry - had to do it!

-> we now resume the normal chatter

johnraff · 2025-05-22 02:13:00

Thanks @HoaS, four worthwhile points.

Head_on_a_Stick wrote:

There doesn't seem to be a problem with running gparted under Wayland for Debian bookworm:

On both bookworm and trixie gparted puts up a pxexec box, so it's running its GUI as root.
But from the nature of the app, this seems hard to avoid.

And thunar now supports the GVFS admin:// backend to allow for root access to the filesystem:

I've just played with this a bit and it seems to sort-of work but be a bit flaky. No "operating as root" warnings, and ability to perfom various actions looks a bit unreliable. Needs more investigation...

For the text editor I think this approach is better:
SUDO_EDITOR=bl-text-editor sudoedit $file

I agree. But that command requires a terminal window - we need something that can be launched from a menu. Again, more investigation...

And finally for the "root terminal"...

BL offers no "root terminal" options in any menu because it's so easy to open a user terminal and run root commands there. No need to worry about GUI privileges.

Head_on_a_Stick · 2025-05-22 06:19:29

johnraff wrote:

it's running its GUI as root

/usr/sbin/gparted is a wrapper script that uses xhost, as suggested earlier in this thread.

johnraff · 2025-05-22 09:55:00

^Isn't xhost granting root permissions to the GUI? As i said, I don't think that's avoidable for gparted. I'll try and dig up the discussion...

#21 2024-08-25 06:39:49

Re: pkexec on Wayland

#22 2024-08-25 09:21:32

Re: pkexec on Wayland

#23 2024-08-25 09:36:52

Re: pkexec on Wayland

#24 2024-08-25 09:51:33

Re: pkexec on Wayland

#25 2024-08-26 03:06:03

Re: pkexec on Wayland

#26 2024-08-26 03:37:11

Re: pkexec on Wayland

#27 2024-08-26 11:59:26

Re: pkexec on Wayland

#28 2024-08-26 16:44:49

Re: pkexec on Wayland

#29 2024-08-27 05:24:15

Re: pkexec on Wayland

#30 2024-11-07 13:09:49

Re: pkexec on Wayland

#31 2024-11-08 04:40:48

Re: pkexec on Wayland

#32 2024-11-08 07:46:13

Re: pkexec on Wayland

#33 2024-11-08 08:21:14

Re: pkexec on Wayland

#34 2024-11-08 08:33:36

Re: pkexec on Wayland

#35 2025-05-21 16:13:15

Re: pkexec on Wayland

#36 2025-05-21 16:55:42

Re: pkexec on Wayland

#37 2025-05-21 23:17:37

Re: pkexec on Wayland

#38 2025-05-22 02:13:00

Re: pkexec on Wayland

#39 2025-05-22 06:19:29

Re: pkexec on Wayland

#40 2025-05-22 09:55:00

Re: pkexec on Wayland

Board footer