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.
Thank you. (I assume that fix will make its way into the next point release, or however it works.)