A.J.Mechelynck wrote: > Micah Cowan wrote: >> Following description lifted from bug filed at >> https://bugs.launchpad.net/ubuntu/+source/vim/+bug/78960 >> >> << >> [EMAIL PROTECTED]:~$ rm .viminfo >> [EMAIL PROTECTED]:~$ ln -s /dev/null .viminfo >> [EMAIL PROTECTED]:~$ ls -l .viminfo >> lrwxrwxrwx 1 sa sa 9 2007-01-12 17:16 .viminfo -> /dev/null >> [EMAIL PROTECTED]:~$ umask 007 >> [EMAIL PROTECTED]:~$ /usr/bin/vim.basic -c 'quit' >> [EMAIL PROTECTED]:~$ ls -l .viminfo >> -rw-rw-rw- 1 sa sa 509 2007-01-12 17:16 .viminfo >> >> As you can see the .viminfo file gets deleted and re-created with >> permissions 666 by vim. >> >> Note that the use of -c 'quit' is just to simplify the bug for >> transcribing here -- I promise you the same thing happens if you use vim >> for editing/saving a document as well. >> >> I consider this a security bug. vim deletes a file without telling me, >> and not only that but when it re-creates it, it ignores my umask by >> making it world writable. This is not what I expected it to do. >> >> I was able to confirm this bug, both in Ubuntu's >> vim-gnome-7.0-164+1ubuntu7 package, and in the latest 7.1b sources. >> >> I also have a separate question: is this an appropriate place to post >> bugs? Specifically, when (a) I am interested in potential discussion >> related to it, and/or (b) I am interested in possibly implementing the >> fix for it? :he bugs suggests submitting bugs to [EMAIL PROTECTED], but from >> the description, it sounds like those go to a single person, and are not >> tracked (so, no opportunity for discussion, and it's hard to know if a >> bug has been reported or what it's status is). >> >> A subject change may be appropriate for answering this separate question. >> > > I suppose it's not expected that your viminfo might be a soft link to a > device. > > To avoid using a viminfo, use > > :set viminfo= > > To have it non-world-readable, what about > > cp -vf /dev/null ~/.viminfo > chmod 600 ~/.viminfo > > I expect that when the viminfo is a "true" file, Vim will respect its > permissions.
Yes, but do you really expect that vim's current behavior when encountering this circumstance is valid? I can imagine that a user could set this environment up, perhaps expecting vim to get an "empty" file whenever it starts up. If they never bother to check up on it, they could be blissfully unaware that vim has just replaced their symlink with a real file, especially one that any user could write to. Is there a good reason not to simply follow symlinks when they are encountered, as this user obviously expected? I realize that unsetting viminfo is preferable to linking .viminfo to /dev/null; but I believe we still have a responsibility to users who just happen to try a different route (perhaps being unaware of the "canonical" method), for which they have a reasonable expectation that it will DTRT. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/
signature.asc
Description: OpenPGP digital signature
