cannot use pkexec

Support
1

I have found a solution, but it only works in my friend’s (fresh) Whonix 15, and not mine. The easy test anyone can do is to do pkexec mousepad from Workstation Terminal. It SHOULD launch the pkexec prompt, as a simple test of its operation.

It does in my friend’s, but it does not in mine. This is literally the latest Whonix OVA I’m trying

Does it work in yours? Can others please test this and report back?

2

Citation required.

Anyone that tests by any linux distributions that do that?

Any user documentation recommending to use pkexec for that?

Could be XyProblem - Greg's Wiki

For editing files with root rights we recommend sudoedit. This was a recent change.

Software Recommendations

Previously we recommended lxsudo mousepad.

3

@Patrick, in Whonix 14 (Stretch), it works. Please see cannot use gparted - #3 by AnonymousUser - these are just examples to test a major policykit problem currently present in Whonix 15.

Here are more examples so you can see what I mean:

  • Synaptic (try launching it from Whisker Menu) - first install via apt install synaptic
  • KDE Partition Manager (install via sudo apt-get install partitionmanager) - it normally is supposed to launch with an admin password prompt.
  • Thunderbird, possibly (haven’t tested). It always prompts with GUI password box when you want to cache your PGP key for the rest of the session. This would be broken due to the same principle as GDebi being broken.
  • Opera, possibly. Tends to do a GUI password prompt upon launch.

Even better example:

  • ZuluCrypt fails to launch in my W15. (this is installed by default.)

Screenshot of what happens:

zulucrypt

This is all a deal-breaker for using Whonix 15. Only noticing it as I’ve started my move from W14. What is going on? Am I the only one whose ZuluCrypt fails to launch in a fresh Whonix 15 OVA?

1 Like
4

@Patrick this should not be a user support thread. If ZuluCrypt doesn’t even launch, then this is a major Whonix 15 bug that needs an active fix. I hope this can be looked into soon, as it’s holding back the end user viability of Whonix 15 period.

5

Need to install a policykit authentication agent.

Please try.

Also need to decide which package would be the most suitable one. Criteria unknown.

6

But in the Whonix 15 there is already this file:

/etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop

containing this line:

Exec=/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1

Is that not a ‘policykit authentication agent’?

OK. To simplify it, for now, can we therefore make it ZuluCrypt.

Again and again I import the Whonix 15 OVA (and I’ve checked its hash to make sure not corrupt), and before doing anything else (after initial wizard), I click on ZuluCrypt from the Whisker Menu and it simply gives that polkit error I’ve provided in the screenshot.

Can you reproduce this? The answer to that question will guide us where to go next.

7

pkexec seems to be a fancy su which won’t work when the root account is locked.

You don’t seem to realise that not every single password prompt is now broken. Only ones using su to switch to the root user are and if those applications are doing that, you can make a bug report to get them to switch to sudo.

I can reproduce it.

1 Like
8

OK, so to fix this problem recently introduced into Whonix 15 that affects a rather core part of the Debian GUI experience that most of us have used for years, we can either:

  • Request upstream developers for dozens of famous packages used by vastly more people than in the Whonix community to change a long-standing element of how every one of their packages work, and if we’re lucky, wait 1-3 years for it to trickle down to Debian stable repo.

or

  • Fix Whonix at our own pace right now. (Very quick, appreciate that.)

There are probably hundreds of well-known packages that use root in the way that Whonix 15 right now has broken.

Of course, I’m with you here, who doesn’t like more security? I’m still interested in Qubes development, even though I’ve chosen amnesic Debian as my host OS security instead.

But we can’t break the universal user experience like this.

So what are we going to do?

9

It will be fixed. Relax.There is no need for extended debate on priorities without contributing to solutions.

2 Likes
10

and suffer a big security decrease…

As pointed out in use sudoedit in Whonix documentation and Whonix software - #22 by Patrick_mobile

RootSudo - Community Help Wiki says

even pkexec is being deprecated by the mainline Ubuntu developers

Probably won’t be long before Debian deprecates it too.

11

As use sudoedit in Whonix documentation and Whonix software - #21 by Patrick says, I’ve read conflicting information about the fate of pkexec. Citation required.

1 Like
12

Thanks @Patrick.

In this situation, I’d ideally hope a solution was found to achieve both needs here. But I wouldn’t want that to delay fixing what I see as a more urgent problem (for basic pkexec to work again, a famous and fundamental part of current Debian). That bug should be rolled back first, then an ‘ideal’ fix researched after that.

Also, you can’t ask users who report bugs to always provide the solutions for them. We all have our place, and reporters can be very helpful. :slight_smile:

13
1 Like
14 
dpkg -S `which pkexec`

policykit-1: /usr/bin/pkexec

Quote PolicyKit - Debian Wiki

While PolicyKit has been replaced by polkit (which rewrote system component, breaking backwards compatibility) in many distributions, Debian continues to use PolicyKit from wheezy through to buster.

Quote

Since version 0.105, released in April 2012,[2][3] the name of the project was changed[ by whom? ] from PolicyKit to polkit to emphasize that the system component was rewritten[4] and that the API had changed, breaking backward compatibility.[5][ dubious – discuss ]

Fedora became the first distribution to include PolicyKit, and it has since been used in other distributions, including Ubuntu since version 8.04 and openSUSE since version 10.3. Some distributions, like Fedora,[6] have already switched to the rewritten polkit.

Quote https://tracker.debian.org/pkg/policykit-1

This is also interesting because at the moment packages by Whonix use lxsudo. Maybe bullseye based Whonix should be ported to use polkit.

1 Like
15

@Patrick Thanks for starting to look into it.

I have found another major feature of XFCE that is also broken due due to the current whonix mod:

When you attach a VDI in VirtualBox to your Whonix-Workstation (as a way to easily expand your storage), you can no longer mount it via GUI in Thunar.

A hard disk item in Thunar appears under Devices (e.g. ‘200 GB Volume’), and when clicking on it, a GUI password prompt should appear to mount it, but nothing does in the current Whonix 15 OVA.

You have to turn off password security in the Thunar and/or UDisks2 policykit files in order to get it to work.

16

Could try this workaround. It replaces pkexec with lxsudo. That might fix all applications.

sudo cp /usr/bin/pkexec /usr/bin/pkexec.backup
sudo rm /usr/bin/pkexec
sudo ln -s /usr/bin/lxsudo /usr/bin/pkexec
1 Like
17

thunar-volman is disabled by default anyway.

18

thunar volman discussion also here:

possibly related:

1 Like
19

That doesn’t fix it. On a fresh Whonix-XFCE-15.0.0.4.9.ova, after doing those 3 commands:

Launching ZuluCrypt still doesn’t work, produces a pop-up:

lxqt-sudo: no backend chosen!

I click OK and then the same ZuluCrypt polkit error as before pops up.

Tried Synaptic as another test: same lxqt-sudo: no backend chosen! error.

20

Try delete the symlink and use pkexec being a wrapper script calling lxsudo instead.

1 Like