Whonix hardcodes kdesudo a few times.
Should I just port Whonix to be using gksu or gksudo?
Or is there yet another, even better alternative? //cc @HulaHoop
[If that is possible (hopefully, probably is)]
(Still need to learn the exact differences between gksu or gksudo and experiment.)
We might not be able to get rid of kdesudo. We may not be able to replace it with gksudo unfortunately.
When /home/user/.Xauthority file does not exist (happened to be in a Qubes Debian DispVM) gksudo aborts with an error message.
Failed to run kwrite as user root.
Unable to copy the user’s Xauthorization file.
Error copying ‘/home/user/.Xauthority’ to ‘/tmp/libgksu-HPjE7g’: No such file or directory
It has an ugly first time popup as well. (Not a blocker.)
Granted permissions without asking for password
The ‘kate’ program was started with the privileges of the root user without the need to ask for a password, due to your system’s authentication mechanism setup.
It is possible that you are being allowed to run specific programs as user root without the need for a password, or that the password is cached.
This is not a problem report; it’s simply a notification to make sure you are aware of this.
[ ] Do not display this message again
I couldn’t figure out yet where the setting is stored after checking that box.
but still possible to solve out (later work around). i dont think any user gonna welcome mixed package between 2 DEs.
I think a wrapper covering most common terminals would be the way to go as it’s more furutre proof down the line and DE agnostic.
Not mix X with Y alone is a bad argument if it’s only for the sake of “not mix X with Y”. That level of complaints is pushing it. Too theoretic. Little to none (and none mentioned) practical implications. It requires a high technical sophistication to analyze this (look at packages; know which package derives from where) plus on top a special character to complain about it. Too small user group. Hard to impossible to please user group. Sometimes I even wonder if they’d be even use Whonix or just complain for the sake of complaining. In short: these kind of complains “not mit X with Y for the sake of not mixing” shall not be Whonix indented target user group.
A usability reason to get rid of kdesudo in this post:
Whonix for VirtualBox with XFCE 14.0.0.9.6 - Release Candidate 1 - Testers Wanted! - #13 by Patrick
This is required for port Whonix from Debian stretch to Debian buster. Therefore have to revisit this now.
Neither kdesudo nor gksudo (package gksu) are available in Debian buster.
gksu REMOVED from testing says:
gksu is dead
pkexec seems not dependent on any desktop, but it does not support graphical (X11) applications by default. Making it work for graphical applications seems quite hacky.
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY program-name
We’d have to create a wrapper for this since this is too much to type for users. But if we have to invent something for something as simple as this, it looks wrong.
kdesudo -u user kate new-file
^ opens text file in current directory. Ok. That’s what everyone is used to?
pkexec -u user env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY kate ./new-file
^ open text file in home folder even though it should be current folder because I was using ./.
So what other options do we have…?
Quote RootSudo - Community Help Wiki
Notwithstanding the earlier warning, it is possible to use sudo with graphical apps provided you add the -H flag. This flag is critical: it properly sets root to its own environment instead of improperly inheriting the user’s environment. Use of the -H flag is mandatory. Failing to use this flag may corrupt critical system files and prevent you from logging in.
With sudo -H almost any graphical app can be launched under root within any 'buntu flavour. This includes each flavour’s default graphical editor and file manager.
An appreciable danger with sudo -H is that the -H flag is easy to forget. And all it takes is one omission for the damage to be done.
Omission of the -H flag could be prevented. We could invent our own wrapper and have users use that.
sudo -H kate
^ results in more weirdness.
Executing Kate with sudo is not possible due to unfixable security vulnerabilities.
Quote RootSudo - Community Help Wiki
Please note that many websites and old threads advise the use of gksu. However, such search results are obsolete. gksudo has not been updated for years and is not even available in Bionic (18.04) and higher. gksu has been replaced by pkexec, but even pkexec is being deprecated by the mainline Ubuntu developers. They have taken the position that file manipulation and editing under root should be restricted to the command line.
“manipulation and editing under root should be restricted to the command line.” - Very bad usability.
If it’s a problem with just kate then switch to something else?
Also since Debian != Ubuntu does deprecating pkexec apply?
HulaHoop via Whonix Forum:
If it’s a problem with just kate then switch to something else?
Yes. No more kate installed by default in Whonix 15 by default.
Also since Debian != Ubuntu does deprecating pkexec apply?
Dunno. I guess not. I hope not. In Debian looks like, as long as there
are maintainers maintaining a package, Debian policy conform and
whatnot, it will be available.
Something else to investigate: lxsu
sudo apt-get install lxqt-sudo --no-install-recommends
Two things here.
lxsu bash
press enter
Prompt frozen. So not a great alternative at this point.
/usr/lib/gateway-shortcuts/tordata
currently results in
pkexec env DISPLAY=:0.0 XAUTHORITY=/home/user/.Xauthority thunar /var/lib/tor
which results in
Authentication required to run `/usr/bin/env' as the super user
An application is attempting to perform an action that requires privileges,
Authentication is required to perform this action.
Bad since it does not show the real application to be run. Therefore rather use lxsu. It’s graphical notification shows much better which command is being run and no policy file has to be invented.
So going to be stuck with lxsu. Starting to report bugs against it.
pkexec in any source code by Whonix:As a graphical Linux distribution we need to choose one package which Provides: polkit-1-auth-agent. Full stop.
In other words, one package which serves as virtual package to provide polkit-1-auth-agent. pkexec by itself does not come with a GUI. A GUI is provided by polkit-1-auth-agent. Not having a package installed that serves as a GUI (i.e. providing polkit-1-auth-agent) results in broken start menu entries and other authentication dialogs. (These would fall back to CLI authentication which at that time isn’t visible.)
There are multiple packages which can do that.
For now, I’ve chosen policykit-1-gnome because sudo apt-get install --no-install-recommends policykit-1-gnome on Whonix 15.0.0.0.4-developers-only resulted in:
Once there is a testers-only version of Whonix you could try other alternatives and we may change to another.