Hello. I read the comment in this thread that my specific issue with Zulucrypt throwing an error are probably unrelated to the subject of this thread.
That said, I wanted to offer some anecdotal details from my experience since the last time I posted a comment on this thread.
If it would be better to open a new thread about this, I will gladly do so.
Steps in this process:
(1) Everything is working properly in my instance of Whonix.
(2) Update/upgrade Whonix to Debian 10/Buster base as instructed.
(3) After reboot, I first got the error regarding “pkexec”, and found this thread. (The only app I used that this affected was Zulucrypt.)
(4) Applied the posted/possible workaround, and was able to start Zulucrypt but not able to open an encrypted volume that had worked fine before upgrade/update to Debian 10/Buster base. That’s the error I had posted about previously that might be unrelated to the “pkexec” error.
Since then:
(5) I opened the original instance of Whonix VM’s (from which this instance was cloned back in July). I went through the exact steps of updating/upgrading as above and duplicated every one of the steps with exactly the same results.
(6) I installed “gnome-disk-utility” which has the ability to attach and open LUKS-encrypted images/volumes. It attached okay, but upon attempting to decrypt it, it throws this error upon failure:
“error unlocking /dev/loop0: The function ‘bd_crytpo_luks_open_blob’ called but not implemented1 (udisks-error-quark; 0)”
Conclusion: I will gladly post this as a new thread if advisable; it is possible that the error involving “pkexec” and this problem of decrypting a previously created LUKS volume are separate issues. The certain overlap is that both manifestations began occurring at the time of updating/upgrading the existing Whonix instance to the Debian 10/Buster base.
This could be done in parallel. But I don’t have much hope given the non-activity of that bug report and little polkit package version number bumps throughout Debian releases. It’s probably “patches welcome”. Also this doesn’t solve this issue in Whonix 15 since polkit changes would have to wait until Debian bullseye based Whonix for the fixed polkit version to trickle down.
Wasn’t sure about it. Just wanted to make sure non-root users cannot influence this behavior.
Agreed. So for Whonix 15 either pkexec to lxqt-sudo redirection or disabling proc-hidepid by default. Which one would you suggest?
hidepid is a really useful feature and as Whonix is a security focused distro, I think it should stay enabled by default with the redirect at the cost of minor breakage.
In Whonix 15.0.0.6.5-developers-only and above this is fixed.
(15.0.0.6.5-developers-only has some unrelated imperfections. Won’t be released. Higher Whonix release tag and testers-only release coming soon.)
The pkexec wrapper in upgraded security-misc package is functional.
Fixed meaning: I successfully used: gdebi, synaptic, gparted.
Yes. Thunar mounting (or auto mounting) of external drives (e.g. a vbox VDI). I can continue to test for you on a Developer OVA. Its current status is it still doesn’t work without giving UDisks2 an explicit policykit exception which is obviously dangerous and not ideal.
pkexec wrapper might be called without us having a chance to know that. Therefore I’ve now added logging when pkexec wrapper is called to systemd journal. (Calls to sudo are similarly logged by Debian default.)
another pkexec related fix (which hopefully won’t lead to more pkexec related regressions):
Due to above change, we at least can now see in journal when pkexec wrapper gets run and what the output of any applications is in case these are failing.
There could be quite a few broken things due to hidepid / pkexec wrapper.
Files containing string path.
#!/bin/bash
for x in $(find /usr/share/polkit-1/actions/ -type f) ; do
echo "$(dpkg -S $x)"
done
How would I test functionality Run Thunar as root? That’s functionality I haven’t discovered yet.
I.e. policykit policy files that don’t contain a /path/to/binary. I’ve read “policykit helps to run an application as non-root while allowing the application to run only these parts as root which require that”.
How would I test the functionality of ktexteditor-data: /usr/share/polkit-1/actions/org.kde.ktexteditor.katetextbuffer.policy?
@Patrick, upgrading to the point release 15.0.0.8.9 in-place, this bug is back again (even in my existing upgraded in-place system in which I had already applied my own manual fix).
I cannot install DEB files with GDebi, cannot launch Synaptic, and ZuluCrypt error at launch.
Investigating my own (re)solution right now and will report back.
Update: This bug is now worse than it was before, and I cannot find a fix. This is all tested on multiple fresh 15.0.0.8.9 OVAs out of the box.
My previous fix of changing ‘auth_admin’ (or ‘no’) to ‘yes’ in various policykit files in /usr/share/polkit-1/actions/ no longer works. (What is overriding that?)
@Patrick that amended code fixed it! GDbei back to normal again. Thank you. (I assume that fix will make its way into the next point release, or however it works.)
I never actually use ZuluCrypt itself.
I didn’t see Thunar external hard drive mounting affected by the recent point release, so with that fix above, at least from my end this issue isn’t present anywhere.