use sudoedit in Whonix documentation and Whonix software

There is the point regarding filename and location change, resulting in wrong syntax highlighting, as described in

Since the files are copied to temporary files, the filename and location, which are often identifying characteristics for filetype detection, are lost. So, where /etc/apache2/apache2.conf would load syntax highlighting suitable for Apache2 configuration files ( set ft returns filetype=apache ), /var/tmp/apache2XXcLFdTD.conf has filetype=conf .

I didn’t observe this issue with mousepad though.

1 Like

You edit it, then shred it? I think you already have issues right there. Say you have a long file, and you remove part of it when you edit, and at some point in the future shred it. Which part gets shredded? if I understand correctly, only the data at the last version of the file.

This is now documented.


Hardcoding mousepad in https://github.com/Whonix/usability-misc/blob/master/usr/lib/default-editor/default_editor.sh is not great. But there is no /etc/alternatives/x-editor or visual.

Debian feature request: please provide /usr/bin/visual
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758228

1 Like

https://github.com/Whonix/usability-misc/blob/master/usr/lib/default-editor/default_editor.sh

1 Like

gksu Removed From Ubuntu, Here's What You Can Use Instead suggests to use gvfs. Example:

gedit admin:///etc/default/apport

Bug #1740618 “Remove gksu from Ubuntu” : Bugs : umit package : Ubuntu saying

Debian has removed gksu. I recommend that we remove gksu and libgksu for Ubuntu 18.04 LTS also.

It is recommended that developers use PolicyKit to only use elevated privileges for the specific actions where it is needed.

It is recommended that users use the gvfs admin backend available in Ubuntu 17.10 and 18.04 LTS. You can do this with the admin:// prefix. For instance, instead of running gksu gedit or gksu nautilus to edit /etc/default/grub, navigate to admin:///etc/default/ and open the grub file.

Ubuntu 17.10’s default session (a themed GNOME on Wayland) does not support gksu. Ubuntu 18.04 switched back to using X instead of Wayland as default but it is expected that Wayland will once again be the default in 18.10.

policykit? gvfs?

Citation from more authoritative sources may be required to learn what the plan for Debian is.

That is because RootSudo - Community Help Wiki contradicts it and says

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.

Also citation required.

1 Like

Very much citation required since RootSudo - Community Help Wiki also says:

March 14, 2019 PLEASE NOTE: This wiki article is being significanly rewritten as it contains a good deal of old, dated and possibly questionable material. Using caution and consulting with others on the Ubuntu Forums or Ask Ubuntu is highly recommended!

New bug I ran into: GUI editing of whonix firewall no longer opens/responds

1 Like

I.e. Try run this manually on command line:

/usr/lib/whonix-firewall/firewall50user
bash -x /usr/lib/whonix-firewall/firewall50user
sudoedit /etc/whonix_firewall.d/50_user.conf
ls -la /etc/whonix_firewall.d/50_user.conf
cat /etc/whonix_firewall.d/50_user.conf

env | grep -i VISUAL

expected output:

VISUAL=mousepad

The VISUAL environment variable influences whether sudoedit will work in GUI or not.

The first three commands open mousepad,

env | grep -i VISUAL

gives the expected out put but the link in the whisker menu doesn;t respond at all.

1 Like

Do contents of whonix-firewall/whonix-firewall50user.desktop at master · Whonix/whonix-firewall · GitHub match contents of file /usr/share/applications/whonix-firewall50user.desktop?

Does /etc/whonix_firewall.d/50_user.conf exist as an empty file?

1 Like

Yes to both questions

1 Like

/usr/share/applications/whonix-firewall50user.desktop calls /usr/lib/whonix-firewall/firewall50user which calls sudoedit /etc/whonix_firewall.d/50_user.conf. The latter does not have a sudoers exception. And probably should not have one anyhow. Since started from start menu (GUI), sudoedit will not ask for password. And we’re not using -A / askpass option.

I don’t think anyone accept ssh-askpass is using sudo aspass option.


This would work:

sudo apt install ssh-askpass
export SUDO_ASKPASS=/usr/bin/ssh-askpass
sudoedit -A /etc/something

We could write a nicer zenity wrapper to ask for the password.

zenity --title "something" --password

zenity is too limited. Couldn’t show a custom message. And inventing this from scratch seems a lot work.


But probably this would be better:

lxsudo env VISUAL="$VISUAL" sudoedit /etc/whonix_firewall.d/50_user.conf

Has a more familiar, consistent GUI. Designed for purpose of password entry and showing the actual command.

Would it be a problem that sudoedit is run as root (through lxsudo)?

1 Like

Yes. That runs mousepad as root which is what sudoedit is meant to prevent. When using lxsudo with sudoedit, mousepad warns that it is running as root. You can also see it running as root with ps aux.

You can use this hack instead

lxsudo sudo -u user env VISUAL="$VISUAL" sudoedit /etc/whonix_firewall.d/50_user.conf
1 Like

Using that now but replaced hardcoded user with $(whoami).

1 Like

This is fixed in the developers repository.

1 Like
1 Like

Although sudoedit better than sudo, But its not safe from security issues (specially when the issue in sudo).

1 Like

4 posts were split to a new topic: vitor - safely edit the Tor configuration file