There is a race condition in vim 7.2 (and probably in earlier too) on POSIX
platforms. Below, there is fragment of strace output related to this problem.
stat64("testfile~", 0xbfc35dbc) = -1 ENOENT (No such file or directory)
stat64("testfile", {st_mode=S_IFREG|0600, st_size=12, ...}) = 0
unlink("testfile~") = -1 ENOENT (No such file or directory)
rename("testfile", "testfile~") = 0
open("testfile", O_WRONLY|O_CREAT|O_TRUNC, 0600) = 3
write(3, "test test test\n"..., 15) = 15
fsync(3) = 0
stat64("testfile", {st_mode=S_IFREG|0600, st_size=15, ...}) = 0
stat64("testfile", {st_mode=S_IFREG|0600, st_size=15, ...}) = 0
close(3) = 0
Problematic situation take place during file saving between rename and open,
open and write as well as write and close syscalls. There are points at
which another process attempting to access file may run into trouble.
There is, for example, possibility to:
- if application, which expects existence of file, would try to open it
between vim rename and open syscalls, it will fail due to lack of this
file,
- if other process creates file with the same name between vim rename and
open syscalls, it will be overriden by vim (it works with symlinks too,
so it can be used by attacker to damage other files),
- if application will read file while vim will write to it, the contents
may be badly read due to temporarily partially record.
Vim rather should create new, its own, temporary file with unique name,
write content, close it and then, atomically rename it to original name.
Regards.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
