Some programs create root-owned files in user $HOME when run under sudo

[Rocco Stanzione]

The first time I noticed this I thought I'd done something wrong. But 5 installations later, my .viminfo is always owned by root, causing certain things to malfunction or not function at all. For example I can't copy and paste text (vim-style) from one file to another, and despite my .vimrc magic my cursor is always on line 1, column 1 when I open a file.

[Rocco Stanzione (trappist)]

After furter reflection, meditation, source package examination and finally experimentation, I see the cause of the problem. The first file I edit, without exception, on a new system is my sources.list. So of course I say `sudo vi /etc/apt/sources.list`. Since I'm using sudo, the .vimrc file is created as root, and since $HOME is preserved when I use sudo with no options, it's created in my home directory. The simplest solution is probably an empty /etc/skel entry for .vimrc?

[Rocco Stanzione (trappist)]

erm, s/vimrc/viminfo/g

[Sebastian Dröge (slomo)]

I can confirm this behaviour here... not sure why it is owned by root though

[Dennis Kaarsemaker (dennis)]

 status Rejected

Use either sudo -H or create it yourself.

[Rocco Stanzione (trappist)]

I can easily work around this. I submitted this bug because:
a) it took me quite a while, even with help from #vim, to figure out why these things weren't working
b) it's probably not atypical that the first file edited after a fresh install must be edited as root
c) the failures happen quietly
therefore
d) I suspect quite a lot of users have a root-owned .viminfo that prevents vim from operating correctly, whether they're aware of it or not.

I can live with this bug being rejected, but I'd appreciate it if someone put some thought into it first. Maybe there could even be a discussion.

[Dennis Kaarsemaker (dennis)]

 status Rejected

There is no bug here: vim does what it's supposed to and writes a .vimrc
to $HOME/.vimrc -- setting $HOME correctly is up to you (aka: use sudo
-H)

[Rocco Stanzione (trappist)]

I agree that vim is doing what it's supposed to do. But the result is a problem that's difficult to detect and even harder to track down. It's a consequence of the way we use sudo, which is a great idea, but not standard, and a lot of standard bugless things fail to accommodate it, so we have to make our own accommodations. For example, we put /sbin in the PATH of mortal users, which other distros don't do, because things like 'sudo ifconfig' wouldn't work otherwise. We could just say 'use sudo /sbin/ifconfig', but we don't. Users are editing files with sudo because they're supposed to, and something that nobody meant to happen (.viminfo is owned by root) is happening. Please leave this bug open until somebody (besides the guy who already confirmed it) can break the tie or something.

[Dennis Kaarsemaker (dennis)]

 status Rejected

Sebastian confirmed the *behaviour* and the behaviour is not a bug in
vim, so please stop unrejecting it. If you think there is something
wrong with the way Ubuntu uses sudo (like: why not use always_set_home
by default in /etc/sudoers) then raise a discussion on more appropriate
channels than a bug report about vim.

[Rocco Stanzione (trappist)]

The problem is caused by vim, though it doesn't have a bug, and the symptoms are in vim. Maybe sudo should be modified, maybe some other package should put an empty .viminfo in /etc/skel, or maybe there's another solution. When the appropriate package is identified to apply the solution to, I'll assign this bug to that package. Meanwhile you're putting an awful lot of energy into making sure this doesn't get fixed. Please don't.

[Paul Sladen (sladen)]

Ubuntu has a philosophy of "It just works", if there is anything we can do to make life saner for people, we should do.

The technically correct action for vim is probably to create the file chown root:root; so fixing the skel sounds a good workaround to me.

Dennis: please don't reject this (again), the case clearly exists; even if (as you are probably technically right) the issue may not be the fault of vim itself. Correcting the location of the issue is much better than a rejection, as it moves the situation forward.

Rocco: can you test the following:

  sudo touch /etc/skel/.viminfo /etc/skel/.vimrc
  sudo adduser test
  su - test
  sudo vi /etc/apt/sources.list
  ls -l ~test/.vimrc

if that is not the correct solution, can you test again for '.vim/...'. Then these can be added to the 'vim' package.

[Rocco Stanzione (trappist)]

Performed that test with some modifications. I didn't test .vimrc, because to my knowledge .vimrc isn't created automatically by vim and isn't an issue (though I probably accidentally said .vimrc once or twice in this bug report). I also of course had to make the test user a sudoer. Anyway the end result looked like this:
-rw-r--r-- 1 test test 757 Aug 29 18:55 .viminfo
which is just what I was hoping for, so putting a skel .vimrc in the vim package should resolve this issue.

[Rocco Stanzione (trappist)]

A note or two for posterity. It was pointed out that other applications are typically run as root the first time and may have similar issues, and would this approach be appropriate for those as well. I only remember seeing one such case before. I don't recall what it was, but I think it had something to do with using my tv tuner card. Anyway, it was different in that the app complained loudly that it couldn't write to its dotfile, so it was simple to diagnose and fix. Vim fails silently here, making it much more difficult. Also, this is only appropriate for vim because it's depended on by ubuntu-minimal, so the change will benefit the first user because vim (and therefore the skel file) will already be on the system. This exact approach might not work or be appropriate for other similar situations.

[Jan Claeys (janc)]

Not really a sollution for this problem, but why don't you use 'sudo -e <filename>' instead of 'sudo vi <filename>' ?

[Jan Claeys (janc)]

Also, I wonder if setting the 'always_set_home' flag in sudoers would have any bad effects (it's the same as always using the -H option)? Because, I think, that way such problems won't happen for any program. And I guess we don't want to add config files to '/etc/skel' for every possible package...

[Colin Watson (cjwatson)]

Adding files to /etc/skel is pretty gross, and recommended against by policy for good reasons. Code changes to avoid the file being owned by root when being invoked by sudo would be better, even though those would be fairly hackish too.

[Paul Sladen (sladen)]

This is /more likely/ to occur because of our encouragement for people to use sudo in Ubuntu. So, we should probably do /something/ about easing the result.

The skel method, to me, seems less intrusive; although if the general feeling is to stick it in the binary, then it should probably go there.

[Jan Claeys (janc)]

I have been running with the 'always_set_home' flag added to the 'Defaults' in sudoers for 10 days now, and I didn't see any problems until now, so that _might_ be a solution...

[Michael R. Head (burner)]

A similar problem occurs with the .nano_history file with nano, so if a patch were to be applied to vim, something similar would be required for nano...

[Rocco Stanzione (trappist)]

A similar solution (an empty /etc/skel/.nano_history) would work for nano, since both vim and nano are part of the default install. For packages that are not, another solution would have to be applied, since the first user may not get the benefit of the skel entry (since it wouldn't be there on a default install).

[Scott Robinson (scott-ubuntu)]

Has everyone forgotten the existence of "sudoedit", which was invented and added to the sudo package for reasons like this?

[Rocco Stanzione (trappist)]

Sudoedit is nice, and it doesn't suffer from this problem. The problem (part of it anyway) is that the people who edit /etc/fstab (say) with vim have probably been using Linux for a while and, out of habit, say 'sudo vi /etc/fstab'. Suggesting the use of sudoedit is fine, but it doesn't solve this problem, because the problem isn't just that .viminfo gets nasty permissions - the problem is that when it does, vim features fail quietly and it's not always easy to figure out why. You don't get permission denied errors on .viminfo (if you did, I would consider that an adequate solution). Things just don't work.

[Martin Sander (forke)]

Hey,
bug #93449 is a duplicate of this one, but as here it hasn't gotten a lot of attention recently.
Could somebody file a bug where it is more appropriate? Obviously it is not vim's fault, so maybe it should be a sudo-bug..

I have spent some hours banging my head against the wall today trying to find out why vim doesn't behave the way I am used to.

[Micah Cowan (micahcowan)]

Some recent discussion currently going on at the vim mailing lists (started on the users list, got migrated to -dev):

http://tech.groups.yahoo.com/group/vimdev/message/46878

[Lesmana Zimmer (lesmana)]

any reason why setting always_set_home in /etc/sudoers is not a solution to this bug?

[Phillip Susi (psusi)]

There is a tradeoff in choosing which home directory to use. By using your own, your config files are used and applications behave the way you have configured them and come to expect them to. By using root's, they use root's config, which usually means defaults, and is not what you expect. The problem can't be solved by sudo. The solution is the empty .vimrc in /etc/skel.

[Barin Montpris (lnxsoul)]

I know it's been a long time since the original bug was reported and the last message was posted. However, I am unable to reproduce this bug on Ubuntu 20.04.2. Perhaps that's because I already have everything mentioned here as my own user. If I rename ~/.vimrc and ~/.viminfo and then run `sudo vi /etc/apt/source.list`, then a default .vimrc and .viminfo are not created in my user directory. I can also see that there is still nothing in /etc/skel related to vim.

It has been 8 years and things do change. I've only been using vim for a couple of years, so it's quite possible that the ~/.vimrc isn't created upon first running `vi` or `vim` anymore.

What should we do with this bug?