Bug 1889576 - 'sudo' resets environment, defaults to vim but should use nano
Summary: 'sudo' resets environment, defaults to vim but should use nano
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: nano
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kamil Dudka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
Depends On:
Blocks: 1854444
TreeView+ depends on / blocked
 
Reported: 2020-10-20 03:51 UTC by Chris Murphy
Modified: 2020-10-29 14:30 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-20 14:55:23 UTC
Type: Bug


Attachments (Terms of Use)
env (2.43 KB, text/plain)
2020-10-20 04:01 UTC, Chris Murphy
no flags Details
set (196.30 KB, text/plain)
2020-10-20 04:01 UTC, Chris Murphy
no flags Details

Description Chris Murphy 2020-10-20 03:51:00 UTC
Description of problem:

When I "virsh edit VM" the xml config is opened in vim.


Version-Release number of selected component (if applicable):
libvirt-client-6.6.0-2.fc33.x86_64

How reproducible:
Always for "admin" user chris; never for "root" user.


Steps to Reproduce:
1. sudo virsh edit nameofvm
2.
3.

Actual results:

Config opens in vim.


Expected results:

Config opens in nano.


Additional info:

'git commit' or 'systemctl edit' I get nano. So for some reason, so far only virsh is using vim. Newly created user has this problem as well.

However, if I 'sudo -i' and then 'virsh edit nameofvm' it opens in nano. So it would seem to be environment and exclusive to virsh.

Comment 1 Chris Murphy 2020-10-20 04:01:25 UTC
Created attachment 1722760 [details]
env

Comment 2 Chris Murphy 2020-10-20 04:01:37 UTC
Created attachment 1722761 [details]
set

Comment 3 Chris Murphy 2020-10-20 04:02:04 UTC
I don't see anything in the environment that relates to editor or vi or vim or virsh.

Comment 4 Erik Skultety 2020-10-20 07:52:15 UTC
(In reply to Chris Murphy from comment #0)
> Description of problem:
> 
> When I "virsh edit VM" the xml config is opened in vim.
> 
> 
> Version-Release number of selected component (if applicable):
> libvirt-client-6.6.0-2.fc33.x86_64
> 
> How reproducible:
> Always for "admin" user chris; never for "root" user.
> 
> 
> Steps to Reproduce:
> 1. sudo virsh edit nameofvm
> 2.
> 3.
> 
> Actual results:
> 
> Config opens in vim.
> 
> 
> Expected results:
> 
> Config opens in nano.
> 
> 
> Additional info:
> 
> 'git commit' or 'systemctl edit' I get nano. So for some reason, so far only
> virsh is using vim. Newly created user has this problem as well.
> 
> However, if I 'sudo -i' and then 'virsh edit nameofvm' it opens in nano. So
> it would seem to be environment and exclusive to virsh.

This is not a bug in virsh/libvirt. Sudo has a default security policy with regards to resetting the environment, thus the EDITOR you have likely set in both your user's and root's .bashrc is discarded, which naturally doesn't happen if you do 'sudo -i' because that's a login shell, hence the environment of that specific user (root in this case) is properly initialized.
You can solve this by either invoking 'sudo EDITOR=/usr/bin/nano virsh edit <domain>' or 'sudo --preserve-list=<comma separated list of envs> virsh edit' or tweak your sudoers file and add env variables there which you desire to be preserved with sudo invocations. As for virsh itself, if neither of VISUAL or EDITOR is set, it will default (hardcoded) to 'vi'.

I'm closing this as NOTABUG per the resolution above.

Comment 5 Daniel Berrangé 2020-10-20 08:20:39 UTC
Also, there's no reason to use sudo with virsh. You can run virsh as non-root and it authenticates automatically. eg    "virsh -c qemu:///system " will authenticate as root, but run virsh as non-root.

Comment 6 Chris Murphy 2020-10-20 14:16:57 UTC
I wonder if as part of the nano by default system-wide feature, there should be a additional tweak to sudoers file so that nano as editor is preserved? It could maybe be done with a drop in configuration that comes along with nano-default-editor package? It's totally non-obvious that the use of sudo should just change the default editor.

Comment 7 Kamil Dudka 2020-10-20 14:55:23 UTC
I believe that the suggestion in comment #5 solves the problem reported in comment #0.

(In reply to Chris Murphy from comment #6)
> I wonder if as part of the nano by default system-wide feature, there should
> be a additional tweak to sudoers file so that nano as editor is preserved?
> It could maybe be done with a drop in configuration that comes along with
> nano-default-editor package?

Not really.

> It's totally non-obvious that the use of sudo
> should just change the default editor.

I think it is obvious to people who know how sudo works.  It resets the environment for a reason.  I do not think that nano-default-editor should change the configuration of sudo in any way.

Comment 8 Chris Murphy 2020-10-20 15:27:04 UTC
>I think it is obvious to people who know how sudo works.

I've been using sudo for 20 years. It's not obvious but is is aggravating and suboptimal UX to have this kind of inconsistency.

It's significantly contrary to the approved system-wide feature change. It's not really the default editor when there's this kind of non-obvious fallback behavior, in effect there are two defaults. Using sudo with 'systemctl edit' does not cause the fallback to vim, it still uses nano - and yes that's because it prefers nano when EDITOR is not set but that just adds to the inconsistency.

See also bug 1889674.

Comment 9 Kamil Dudka 2020-10-20 15:53:59 UTC
(In reply to Chris Murphy from comment #8)
> I've been using sudo for 20 years.

So you know why sudo resets the environment I guess.

> It's not obvious but is is aggravating
> and suboptimal UX to have this kind of inconsistency.

What exactly are you proposing that you think is more consistent?

Comment 10 Chris Murphy 2020-10-20 17:36:53 UTC
>So you know why sudo resets the environment I guess.

Not really, only vaguely. As every desktop user is de facto sysadmin, I posit the overwhelming majority who use sudo have no idea that sudo resets environment or why. And it's not especially relevant. I can accept all explanations at face value, as I have no quarrel with them. The UX inconsistency is what's relevant.

>What exactly are you proposing that you think is more consistent?

(a) Cause EDITOR=/usr/bin/nano to be included in the sudo environment by default.
(b) Revert the change.

It's that annoying. I'd rather be stuck with vim by default across the board, which I do not like, than being jerked around with editor selection by roulette.

Comment 11 Kamil Dudka 2020-10-20 21:20:31 UTC
(In reply to Chris Murphy from comment #10)
> (a) Cause EDITOR=/usr/bin/nano to be included in the sudo environment by default.

This would result in equally bad inconsistency the other way around.  If a user overrode the system-provided default back to vim, `sudo foo` would give them nano again.

> (b) Revert the change.

This is not an option at this point.  You can propose the revert as a Fedora 34 change but I do not think that such a proposal would be supported much by the community.

Comment 12 Michael Catanzaro 2020-10-20 22:04:40 UTC
I admit this is non-ideal, but I kinda think 'sudo <anything that starts a text editor>' is more an edge case not worth worrying about than a serious problem. If you're having fun with virsh, you can probably figure out how to exit vim?

Comment 13 Chris Murphy 2020-10-21 16:24:47 UTC
Also affects 'sudo visudo' which results in vim not nano.

Comment 14 Chris Murphy 2020-10-21 17:00:17 UTC
Draft write up for common bugs: 

When using sudo the user environment variables do not get passed to the root account. This can result in inconsistency which editor will be used. To ensure nano is used as the editor, use `sudo EDITOR=/usr/bin/nano <command>'. Or a more persistent option is a drop-in file in /etc/sudoers.d/ containing:
Defaults env_keep += "EDITOR"

Comment 15 Kamil Dudka 2020-10-21 18:50:35 UTC
Why not just `sudo -i <cmd>` as suggested above?

Comment 16 Kamil Dudka 2020-10-21 18:55:45 UTC
(In reply to Chris Murphy from comment #14)
> Or a more persistent option is a drop-in file in /etc/sudoers.d/ containing:
> Defaults env_keep += "EDITOR"

You are suggesting users to shoot themselves in the foot.  This will lead to arbitrary code execution in case sudo is run from an untrusted environment.

Comment 17 Chris Murphy 2020-10-21 22:21:46 UTC
Draft v2 write up for common bugs: 

When using sudo the user environment variables do not get passed to the root account by default. This can result in inconsistency which editor will be used. When performing editing tasks in conjunction with sudo, you can ensure $EDITOR is used by using `sudo -i <command>'.

Comment 18 Kamil Dudka 2020-10-22 06:53:43 UTC
Much better.  Thanks for the update!


Note You need to log in before you can comment on or make changes to this bug.