Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
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 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. -- hundred-and-one symptoms of being an internet addict: 111. You and your friends get together regularly on IRC, even though all of you live in the same city. /// 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///
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
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
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
Micah Cowan wrote: Bram Moolenaar wrote: [...] 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. Maybe you're missing the fact that /dev/null is crw-rw-rw- i.e. world-readable and -writable? Best regards, Tony. -- You can take all the impact that science considerations have on funding decisions at NASA, put them in the navel of a flea, and have room left over for a caraway seed and Tony Calio's heart. -- F. Allen
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
A.J.Mechelynck wrote: Micah Cowan wrote: Bram Moolenaar wrote: [...] 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. Maybe you're missing the fact that /dev/null is crw-rw-rw- i.e. world-readable and -writable? No, I'm not missing that. Why should that make a difference? It is, after all, a special file; and only root would be able to replace it with something else. Anyway, Bram was saying that it's a general security hole, not just for when /dev/null is the target. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
Micah Cowan wrote: A.J.Mechelynck wrote: Micah Cowan wrote: Bram Moolenaar wrote: [...] 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. Maybe you're missing the fact that /dev/null is crw-rw-rw- i.e. world-readable and -writable? No, I'm not missing that. Why should that make a difference? It is, after all, a special file; and only root would be able to replace it with something else. Anyway, Bram was saying that it's a general security hole, not just for when /dev/null is the target. Yes, but when a viminfo exists, Vim re-creates it with the same permissions. IIUC, a link inherits the permissions of the target: here, rw-rw-rw-. Instead of linking to /dev/null, make sure your viminfo is not world-writable, and it will stay that way. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 231. You sprinkle Carpet Fresh on the rugs and put your vacuum cleaner in the front doorway permanently so it always looks like you are actually attempting to do something about that mess that has amassed since you discovered the Internet.
Re: [Bulk] Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
A.J.Mechelynck wrote: Micah Cowan wrote: A.J.Mechelynck wrote: Micah Cowan wrote: Bram Moolenaar wrote: [...] 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. Maybe you're missing the fact that /dev/null is crw-rw-rw- i.e. world-readable and -writable? No, I'm not missing that. Why should that make a difference? It is, after all, a special file; and only root would be able to replace it with something else. Anyway, Bram was saying that it's a general security hole, not just for when /dev/null is the target. Yes, but when a viminfo exists, Vim re-creates it with the same permissions. IIUC, a link inherits the permissions of the target: here, rw-rw-rw-. Instead of linking to /dev/null, make sure your viminfo is not world-writable, and it will stay that way. Best regards, Tony. Tony, Out of curiosity, what would vim do in this case: cp -f /dev/null ~/.viminfo chmod 400 ~/.viminfo ? Would it give any write errors? Would it delete and recreate? Would the file be left blank on exit? I guess intuitively I would expect the file to be left blank (unmodified) without vim giving me any errors. But IIUC, vim would, on exit, actually silently delete the blank file, and create a new one with new contents with the permissions set to r. Is this correct? Thanks! -Robert
Re: [Bulk] Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
Robert Lee wrote: A.J.Mechelynck wrote: Micah Cowan wrote: A.J.Mechelynck wrote: Micah Cowan wrote: Bram Moolenaar wrote: [...] 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. Maybe you're missing the fact that /dev/null is crw-rw-rw- i.e. world-readable and -writable? No, I'm not missing that. Why should that make a difference? It is, after all, a special file; and only root would be able to replace it with something else. Anyway, Bram was saying that it's a general security hole, not just for when /dev/null is the target. Yes, but when a viminfo exists, Vim re-creates it with the same permissions. IIUC, a link inherits the permissions of the target: here, rw-rw-rw-. Instead of linking to /dev/null, make sure your viminfo is not world-writable, and it will stay that way. Best regards, Tony. Tony, Out of curiosity, what would vim do in this case: cp -f /dev/null ~/.viminfo chmod 400 ~/.viminfo ? Would it give any write errors? Would it delete and recreate? Would the file be left blank on exit? I guess intuitively I would expect the file to be left blank (unmodified) without vim giving me any errors. But IIUC, vim would, on exit, actually silently delete the blank file, and create a new one with new contents with the permissions set to r. Is this correct? Thanks! -Robert Let's find out (and, first, move my usual viminfo out of the way by renaming...) Logged-in as root: the viminfo is overwritten with non-zero length and -rw---. But root can write anything. Let's retry with a different login. At Vim shutdown: E137: viminfo file is not writable: /home/tonymec/.viminfo ls -l .viminfo -r 1 tonymec users 0 2007-05-12 23:52 .viminfo The file remains zero-length and readonly. Best regards, Tony. -- Last week a cop stopped me in my car. He asked me if I had a police record. I said, no, but I have the new DEVO album. Cops have no sense of humor.
Bug: .viminfo file gets deleted and re-created with 666 permissions
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. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
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. Best regards, Tony. -- The Army is a place where you get up early in the morning to be yelled at by people with short haircuts and tiny brains. -- Dave Barry
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
Micah Cowan [EMAIL PROTECTED] writes: Is there a good reason not to simply follow symlinks when they are encountered, as this user obviously expected? If it did follow the symlink to /dev/null, and tried to read from that device, it would fail. You can't (or at least, shouldn't) read from /dev/null because it's a sink, not a source. What kind of behavior would you expect, trying to read from /dev/null? 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. I think soft linking a file that is meant to be both read and written to the bit bucket demonstrates that the user has just enough knowledge to be dangerous but without knowing exactly how to get what they want. As that kind of a user, I would expect an error message of some sort, in this situation. -- Taylor Venable [EMAIL PROTECTED] http://www.metasyntax.net/
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
Taylor Venable wrote: [...] If it did follow the symlink to /dev/null, and tried to read from that device, it would fail. You can't (or at least, shouldn't) read from /dev/null because it's a sink, not a source. What kind of behavior would you expect, trying to read from /dev/null? [...] Reading from /dev/null wouldn't fail (in the sense of giving a read error): it would give an end-of-file signal. /dev/null is both a source (behaving as always at end-of-file) and a sink (writing to it always succeeds but the data is silently discarded). Try copying /dev/null to a valid but nonexistent filename, and you'll get a zero-length file with no error. Or if the file exists, cp -f /dev/null filename will truncate it to zero length. On Ms-Dos 2 and higher, the NUL device inherited the same behaviour, in (IIUC) conscious imitation of Unix. Best regards, Tony. -- Osborn's Law: Variables won't; constants aren't.
