<div dir="ltr"><div class="GmSign">On Tue, Oct 25, 2016 at 2:48 AM monty <<a href="mailto:monty2@programmer.net">monty2@programmer.net</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> This commit fixes race conditions in sqFilePluginBasicPrims.c's sqFileOpen() and buffer overflows in sqUnixFile.c 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.<br class="gmail_msg">
<br class="gmail_msg">
I don't have a Github account so I attached the commit as a "git format-patch" patch that you can apply with "git am". Details of the issues fixed follow.<br class="gmail_msg"></blockquote><div><br></div><div>Thanks for submitting the patch. I've opened the following pull request on your behalf:</div><div><a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/82">https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/82</a><br></div><div><br></div><div>I'm not sure who will review this, but I think it's clear that we need to discuss this here on the mailing list. :)</div><div><br></div><div>Fabio</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
sqFileOpen() issues:<br class="gmail_msg">
<br class="gmail_msg">
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.<br class="gmail_msg">
<br class="gmail_msg">
sqUnixFile.c issues:<br class="gmail_msg">
<br class="gmail_msg">
Evaluate this in a Pharo5/6 image with a recent SpurVM:<br class="gmail_msg">
name := String newFrom: ((1 to: 10000) collect: [ :e | $a ]).<br class="gmail_msg">
(name, '/', name) asFileReference writeStream.<br class="gmail_msg">
it should crash with a stack trace with dir_EntryLookup() on top. I fixed it by cleaning up sqUnixFile.c, making it use safer string functions adapted from BSD's strlcpy()/strlcat(), added checks throughout for truncation, removed obsolete includes, and made unexternally referenced global vars static. The iOS branch uses strlcpy()/strlcat() directly, but we sadly can't assume all non-BSDs like Linux have them, so I inserted renamed versions, which is common: <a href="http://marc.info/?l=openbsd-tech&m=138733933417096&w=2" rel="noreferrer" class="gmail_msg" target="_blank">http://marc.info/?l=openbsd-tech&m=138733933417096&w=2</a><br class="gmail_msg">
<br class="gmail_msg">
The diff is smaller than it looks, because I ran sqUnixFile.c through Lindent to make it easier for me to edit and replaced the function-generating macros in sqUnixCharConv.c with their output ("gcc -E" with minor awk post-processing).<br class="gmail_msg">
</blockquote></div></div>