On 5/10/07, Micah Cowan <[EMAIL PROTECTED]> wrote:
Bram Moolenaar wrote:
> Micah Cowan wrote:
>> Vincent BEFFARA wrote:
>>> 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.
I don't think it was suggested that we use a different file. I think it
was suggested that vim not automatically create .viminfo with euid's
ownership, if $HOME isn't owned by euid. I still think that this part of
it (which was Vincent's) is a good idea, despite your good points wrt
'verbose' and giving away files (which was my idea).
>> 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.
Good point. Although, I have a difficult time envisioning how such a
scenario could take place, and it not be the same user reading viminfo
that was running as the root with HOME set that way. But better safe
than sorry.
>> 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.
Hm... but the "typical user" isn't going to necessarily going to think
to do this.
IMO, the user should just be able to run typical commands like "sudo vim
/some/important/file" and have it "just work", without having to think
to himself "Gee, I'd better set my HOME directory properly" or "better
make sure I run it myself first" or "better put it into verbose mode".
Sure, the user would've been better off running "sudo -He ..." instead,
but most users never ever do. It could be argued that this is the user's
miseducation; but my philosophy is that when an erroneous usage pattern
is common, then the error ceases to lie with the user, and becomes an
error in the interface.
However, if it were decided that we will have vim balk at creating
.viminfos that are mismatched to the root user, then I probably wouldn't
care overly much whether vim complains about existing ownership problems
overly much.
Perhaps an option could be added to control this (in case a user should
/want/ a root .viminfo in a regular user home dir, for some reason),
with the default set for non-creation.
As an alternative, what about vim nusing a uid-based name for .viminfo,
when it detects the ownership mismatch? Say, .viminfo-u%d, where %d is
vim's euid?
Couldn't we set up that latter part manually somehow with scripts?
Like, if I am root, viminfo is .viminfo-ux and otherwise, viminfo is
.viminfo-uy?
-fREW
