Branch: refs/heads/monty_fix_fopen_race
Home:
https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: ac49591e3c3a2f30c5492023c992d9ef75105872
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ac49591e3c3a2f30c5492023c992d9ef75105872 Author: Nicolas Cellier <
[hidden email]>
Date: 2017-05-25 (Thu, 25 May 2017)
Changed paths:
M platforms/Cross/plugins/FilePlugin/FilePlugin.h
M platforms/Cross/plugins/FilePlugin/sqFilePluginBasicPrims.c
Log Message:
-----------
Cosmetic changes
- unify style: char* x -> char *x
- rename misleading sqFileNameIndex -> sqFileName
- rename oldName -> sqOldName because we have to distinguish squeak names and c names
- remove dead code #if 0
- call setFile with NULL rather than 0 to avoid making a pointer from integer warning
Commit: c1db1eb40b73373b4e4fe6541cda74c8c742edc7
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c1db1eb40b73373b4e4fe6541cda74c8c742edc7 Author: Nicolas Cellier <
[hidden email]>
Date: 2017-05-25 (Thu, 25 May 2017)
Changed paths:
M platforms/Cross/plugins/FilePlugin/FilePlugin.h
M platforms/Cross/plugins/FilePlugin/sqFilePluginBasicPrims.c
M platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c
Log Message:
-----------
Fix possible race condition in unix FilePlugin sqFileOpen
From original post of Monty
http://forum.world.st/Please-review-and-merge-A-commit-to-fix-race-conditions-is-sqFileOpen-buffer-overflows-in-sqUnixFilee-td4920046.htmlThis commit fixes race conditions in sqFilePluginBasicPrims.c's sqFileOpen() and adds sqFileOpenNew() to support a new primitive to open only new files for IO atomically using open() with O_CREAT|O_EXCL and the equivalent on Windows, failing if they already exist. This will hopefully eventually replace any in-image code that tests for a file's existence before opening it for writing and creation/truncation, a classic race condition.
sqFileOpen() issues:
Look at the current implementation. It tries fopen() with "r+b", reading/writing of an existing file, then if that fails, with "w+b", reading/writing of a new or truncated file. If the file is created and modified elsewhere between the first and second fopen(), you get unintentional truncation with potential data loss. There's also a minor race condition involving the setting of Mac file characteristics. The fix is replacing use of fopen() with the more general sys call open() and fdopen() after and proper error checking throughout.
Compare:
https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/ac49591e3c3a^...c1db1eb40b73