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.
Created attachment 1722760 [details] env
Created attachment 1722761 [details] set
I don't see anything in the environment that relates to editor or vi or vim or virsh.
(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.
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.
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.
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.
>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.
(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?
>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.
(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.
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?
Also affects 'sudo visudo' which results in vim not nano.
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"
Why not just `sudo -i <cmd>` as suggested above?
(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.
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>'.
Much better. Thanks for the update!