Micah Cowan wrote:
> Copying the dev list. The missing context is that running vim via sudo
> before having run it as regular user, causes permission problems with
> the created .viminfo file (and others?).
>
> Vincent BEFFARA wrote:
> >>> Wonderful, the problem really is about permission of .viminfo!
> >>>
> >>> I noticed that you considered this to be a bug, but is this bug belon> gs
> >>> to
> >>> "sudo" or "vim"?
> >>>
> >>> i.e. for non-interactive "su" of "root", vim will save at user $HOME >
> >>> with
> >>> root permission.
> >> FYI, this same issue was discussed at
> >> https://bugs.launchpad.net/ubuntu/+bug/58002
> >
> > From that discussion it would appear that it is a bug of neither, but
> > rather of Ubuntu itself : sudo (as configured there) preserves $HOME,
> > vim sees it and uses it to create .viminfo if it is not there. The
> > natural fix is to put the right option in the sudo config file
> > (always_set_home or something sounding like that).
>
> Except that this isn't always what is desired. And, if it's a bug of
> Ubuntu, it's also a bug of every other distribution I've ever known
> (thought there probably are some of which I'm aware, that set this).
>
> The biggest beef I would have with setting that option is that there
> doesn't appear to be a way to /disable/ it for individual cases :p
> ...still, I can't envision a reasonable case where the user couldn't
> simply type out his own home directory (~user instead of ~?), or if
> necessary set the environment himself within the sudo command, so it may
> be a reasonable solution.
>
> > However, it would be nice of vim to always test that it owns the $HOME
> > directory before creating files there. Would it break anything ?
>
> I think this would be a good idea as well. One could argue that if we
> reason this way for vim, we should reason this way about everything that
> ever creates config files in the user's home directory; however, not
> every such thing can be expected to be run as root, and editors--and
> most particularly vim--are extremely likely to be run as root, so I
> think it's not unreasonable to ask them to take on this responsibility.
And what if root always uses $HOME/.viminfo, where $HOME is the only
person who can be root? It might be that there is no root home
directory.
Let's keep it simple: $HOME/.viminfo is the default viminfo file. If
you want to use another file you have to tell Vim.
> Perhaps rather than simply avoiding file creation, in the case of root
> we could set the file's owner to the real id/gid, instead of the
> effective one. This option is unavailable when the user is sudoing as
> non-root, but this seems much less likely to happen before having run it
> normally, than running under sudo is.
Giving away a file is a big no-no for security reasons. Root may yank
text in a register that a normal user is not supposed to see and this
ends up in the viminfo file.
> Another issue, which was touched on in that Ubuntu bug report, is that
> vim doesn't warn or anything when it can't open .viminfo. Perhaps it
> should distinguish between ENOENT and EPERM, and warn in the latter
> case? It should possibly also warn in the event that it decides to
> change ownership as above (if this is decided to be a good idea), or
> when it is not created because of non-root, non-HOME-owner effective
> user id.
:set verbose=1
When ACLs are used there are many ways reading a file can fail. Just
mentioning that it failed should be sufficient, the user will have to
figure out why. That's better than a wrong message.
--
>From "know your smileys":
:-| :-| Deja' vu!
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
