Bug: .viminfo file gets deleted and re-created with 666 permissions

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug: .viminfo file gets deleted and re-created with 666 permissions

Micah Cowan-2
Following description lifted from bug filed at
https://bugs.launchpad.net/ubuntu/+source/vim/+bug/78960

<<
sa@inyo:~$ rm .viminfo
sa@inyo:~$ ln -s /dev/null .viminfo
sa@inyo:~$ ls -l .viminfo
lrwxrwxrwx 1 sa sa 9 2007-01-12 17:16 .viminfo -> /dev/null
sa@inyo:~$ umask 007
sa@inyo:~$ /usr/bin/vim.basic -c 'quit'
sa@inyo:~$ 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 [hidden email], 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 (260 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug: .viminfo file gets deleted and re-created with 666 permissions

A.J.Mechelynck
Micah Cowan wrote:

> Following description lifted from bug filed at
> https://bugs.launchpad.net/ubuntu/+source/vim/+bug/78960
>
> <<
> sa@inyo:~$ rm .viminfo
> sa@inyo:~$ ln -s /dev/null .viminfo
> sa@inyo:~$ ls -l .viminfo
> lrwxrwxrwx 1 sa sa 9 2007-01-12 17:16 .viminfo -> /dev/null
> sa@inyo:~$ umask 007
> sa@inyo:~$ /usr/bin/vim.basic -c 'quit'
> sa@inyo:~$ 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 [hidden email], 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
Reply | Threaded
Open this post in threaded view
|

Re: Bug: .viminfo file gets deleted and re-created with 666 permissions

Micah Cowan-2
A.J.Mechelynck wrote:

> Micah Cowan wrote:
>> Following description lifted from bug filed at
>> https://bugs.launchpad.net/ubuntu/+source/vim/+bug/78960
>>
>> <<
>> sa@inyo:~$ rm .viminfo
>> sa@inyo:~$ ln -s /dev/null .viminfo
>> sa@inyo:~$ ls -l .viminfo
>> lrwxrwxrwx 1 sa sa 9 2007-01-12 17:16 .viminfo -> /dev/null
>> sa@inyo:~$ umask 007
>> sa@inyo:~$ /usr/bin/vim.basic -c 'quit'
>> sa@inyo:~$ 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 [hidden email], 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 (260 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug: .viminfo file gets deleted and re-created with 666 permissions

Taylor Venable
Micah Cowan <[hidden email]> 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
[hidden email]
http://www.metasyntax.net/
Reply | Threaded
Open this post in threaded view
|

Re: Bug: .viminfo file gets deleted and re-created with 666 permissions

A.J.Mechelynck
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.

Reply | Threaded
Open this post in threaded view
|

Re: Bug: .viminfo file gets deleted and re-created with 666 permissions

Micah Cowan-2
In reply to this post by Taylor Venable
Taylor Venable wrote:
> Micah Cowan <[hidden email]> 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?

As Tony has indicated, /dev/null is indeed intended to be read as well
as written.

>> 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.
You may think that. My own thoughts are that this is an extremely common
Unix idiom, and should be handled accordingly.

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/


signature.asc (260 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug: .viminfo file gets deleted and re-created with 666 permissions

Bram Moolenaar
In reply to this post by Micah Cowan-2

Micah Cowan wrote:

> Following description lifted from bug filed at
> https://bugs.launchpad.net/ubuntu/+source/vim/+bug/78960
>
> <<
> sa@inyo:~$ rm .viminfo
> sa@inyo:~$ ln -s /dev/null .viminfo
> sa@inyo:~$ ls -l .viminfo
> lrwxrwxrwx 1 sa sa 9 2007-01-12 17:16 .viminfo -> /dev/null
> sa@inyo:~$ umask 007
> sa@inyo:~$ /usr/bin/vim.basic -c 'quit'
> sa@inyo:~$ 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 -- [hidden email] -- 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    ///
Reply | Threaded
Open this post in threaded view
|

Re: Bug: .viminfo file gets deleted and re-created with 666 permissions

Micah Cowan-2
Bram Moolenaar wrote:

> Micah Cowan wrote:
>
>> Following description lifted from bug filed at
>> https://bugs.launchpad.net/ubuntu/+source/vim/+bug/78960
>>
>> <<
>> sa@inyo:~$ rm .viminfo
>> sa@inyo:~$ ln -s /dev/null .viminfo
>> sa@inyo:~$ ls -l .viminfo
>> lrwxrwxrwx 1 sa sa 9 2007-01-12 17:16 .viminfo -> /dev/null
>> sa@inyo:~$ umask 007
>> sa@inyo:~$ /usr/bin/vim.basic -c 'quit'
>> sa@inyo:~$ 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 (260 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug: .viminfo file gets deleted and re-created with 666 permissions

A.J.Mechelynck
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
Reply | Threaded
Open this post in threaded view
|

Re: Bug: .viminfo file gets deleted and re-created with 666 permissions

Micah Cowan-2
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 (260 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug: .viminfo file gets deleted and re-created with 666 permissions

A.J.Mechelynck
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.
Reply | Threaded
Open this post in threaded view
|

Re: [Bulk] Re: Bug: .viminfo file gets deleted and re-created with 666 permissions

Robert Lee-7
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
Reply | Threaded
Open this post in threaded view
|

Re: [Bulk] Re: Bug: .viminfo file gets deleted and re-created with 666 permissions

A.J.Mechelynck
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."