Bram Moolenaar 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. > > Do you seriously believe that when you create a symlink to /dev/null > that things continue to work normally? Come on...
The above were not my words; they were from the bug reporter, as I said (though I didn't make it clear that I didn't report the bug, I suppose). However, to answer your question: I would expect such a common idiom to work, at least in the case of files that are given to vim. Since .viminfo is a file that vim would supposedly generate and manage itself, the case may be less strong. > The solution is simple: Don't create a link in place of the .viminfo > file. And certainly not to /dev/null. > > Background info: When Vim finds an existing .viminfo file, it writes the > new info into a temp file (since it's still reading from the existing > one it can't be overwritten). When finished the temp file is moved in > place of the old .viminfo and owner and protection are set to match the > original. > > Vim intentionally doesn't follow symlinks for .viminfo, because that can > be used for a symlink attack, a security issue. How so? The user won't be able to attack files he doesn't have write permission to, and other users wouldn't be running from his .viminfo, AFAICT. And the user shouldn't have permission to replace other users' .viminfo's with a symlink... so I'm missing something. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/
signature.asc
Description: OpenPGP digital signature
