vim security hole

[hazel]

Yesterday, while browsing in the newbie forum, I found something that astonished me. Someone had made a read-only file, loaded it into vi, altered it, and successfully written the altered version to disk by using the w! command. He was flabbergasted and I'm not surprised.

I googled and found another thread on the same problem. It can be fixed by setting a configuration flag in .vimrc but that is hardly the point. The system should not allow this kind of behaviour in any program.

I did some tests and found the following:
1) It only happens when you invoke vim as vim, not if you invoke it as vi.
2) It only happens if you own the read-only file. You can't use this hole to overwrite system files.

vi/vim has an internal "read-only" mode which you can specify explicitly, and which is automatically invoked when the source file is read-only. It is quite reasonable that this mode can be revoked on demand and that vim should then try to write to the disk. It is not reasonable that the kernel should carry out the operation.

How could this happen?

[Lazydog]

How do you consider this a security hole? It warns you that the file is ro and then allows you to over ride this only on files that you own.

It would be different if the system just over wrote the file without informing you or allowed you to modify someone else's file.

[hazel]

How do you consider this a security hole? It warns you that the file is ro and then allows you to over ride this only on files that you own.

No, actually it doesn't. The message you get (at least from vim 7.3) is : "readonly option is set (add ! to override)". In other words, it warns you that vim is operating in read-only mode (which it might well be doing because you explicitly asked it to) but it doesn't tell you that, in addition, the source file's permissions are set to read-only and that you will be overriding this too if you use the ! operator.

I don't know about other people, but if I set a file's permissions to read only, it would be because I wanted a safety net against accidental corruption of that file. I would certainly expect any editor I invoked to view the file to work in read-only mode, but I would also expect that, if I (in a moment of carelessness) overrode that, the permissions system would act as a backstop.

I think I know now how the thing happens; vim must be temporarily changing the file mode to perform the write operation (which is of course legal if the file belongs to you). But I don't think it should do that. It's not expected behaviour. Certainly it should not do it without giving you a much more informative warning

[Lazydog]

No, actually it doesn't. The message you get (at least from vim 7.3) is : "readonly option is set (add ! to override)". In other words, it warns you that vim is operating in read-only mode (which it might well be doing because you explicitly asked it to) but it doesn't tell you that, in addition, the source file's permissions are set to read-only and that you will be overriding this too if you use the ! operator.

Actually vim is not working in ro mode but the file is ro. What it is telling you is the file you are presently editing is marked as read-only and you can over ride this setting if you would like. At no time does it overwrite the file if you have not informed it to do so.

I don't know about other people, but if I set a file's permissions to read only, it would be because I wanted a safety net against accidental corruption of that file. I would certainly expect any editor I invoked to view the file to work in read-only mode, but I would also expect that, if I (in a moment of carelessness) overrode that, the permissions system would act as a backstop.

If you are viewing a ro file with vim and then exit, without editing the file, with :q nothing is done to the file. If you are just viewing a ro file and not planning on editing where is the problem?

I believe this option is in vim to override the ro setting because if you were to edit the file and forget that it is ro you don't have to worry about losing content and you can still save the file. That said, a little common sense goes a long way. It tells you the file is ro and if you decide to edit and save it anyway the issue then is not the software being used but the user himself.

Think of it another way, can you delete a file that is ro? Are you given a warning that the file is ro first to which you must respond to before it is deleted? The same is true with vim.

Going with what you are saying you should not be allowed to delete a ro file either because you might delete it by mistake (which I am sure many of us have done at one time or another).

If you are editing a ro file and vim tells you it is ro, you have to decide if you want to continue or not. Any mistakes made here are the users fault not the program just like deleting files is not the systems fault.

I think I know now how the thing happens; vim must be temporarily changing the file mode to perform the write operation (which is of course legal if the file belongs to you). But I don't think it should do that. It's not expected behaviour. Certainly it should not do it without giving you a much more informative warning

What more warning do you need? vim tells you it is ro, just like deleting a ro file does, and it is your choice to override it or not. This is the behavior I expect. It warns me and allows me, the user, to make the choice. It does nothing without me telling it to.

[Rubberman]

I have always considered this behavior as "convenient, but evil"...

Personally, I tend to agree with Hazel, in that if you have made a file RO in the file system, then an editor should respect that, regardless. In any case, this is a situation of FAD (functions as designed), but we can argue that it is a design flaw I think.

[Manko10]

I've also always considered it as a feature, not a bug or security hole. The exclamation point is the "Quit rabbiting on, I know damn well what I'm doing" ex operator, so I this doesn't surprise me.