Spotting the Sin During Code Review

In order to spot areas where concurrency can cause problems, you need to first look in your own code, and at the library functions that you call. Nonreentrant code will manipulate variables declared outside local scope, like global or static variables. If a function uses a static internal variable, this will also make the function nonreentrant. While using global variables is generally a poor programming practice that leads to code maintenance problems, global variables alone do not add up to a race condition. The next ingredient is that you must be able to change the information in an uncontrolled manner. For example, if you declare a static member of a C++ class, that member is shared across all instances of the class and becomes in essence a global. If the member gets initialized upon class load, and is only read afterwards, you dont have a problem. If the variable gets updated, then you need to put locks in place so that no other execution context is able to modify it. The important thing to remember in the special case of a signal handler is that the code must be reentrant, even if the rest of the application isnt concerned about concurrency issues.

Look carefully at signal handlers, including all the data they manipulate.

The next case of race conditions to be concerned with is the case of processes external to your own interfering with your process. Areas to look for are the creation of files and directories in publicly writable areas, and the use of predictable file names .

Look carefully at any case where files (such as temporary files) are created in a shared directory (such as /tmp or /usr/tmp in UNIX-like systems or \Windows\temp on Microsoft systems). Files should always be created in shared directories using the equivalent of the C open () call O_EXCL option, or CREATE_NEW when calling CreateFile, which only succeeds if a new file is created. Wrap this request in a loop that continuously creates new filenames using truly random inputs and tries again to create the file. If you use properly random characters (being careful to only map to legal characters for your file system), the chances of needing to call it twice will be low. Unfortunately, Cs fopen() call doesnt have a standard way to request O_EXCL, so you need to use open() and then convert the return value to a FILE* value. On a Microsoft system, not only are the native Windows API calls like CreateFile more flexible, but also they tend to perform better. Never depend on just routines like mktemp(3) to create a new filename; after mktemp(3) runs, an attacker may have already created a file with the same name . The UNIX shell doesnt have a built-in operation to do this, so any operation like ls > /tmp/list.$$ is a race condition waiting to happen; shell users should instead use mktemp(1).