A race condition is anomalous behavior caused by the unexpected dependence on the relative timing of events. In other words, a programmer incorrectly assumed that a particular event would always happen before another.
Some of the common causes of race conditions are signals, access checks, and file
opens. Signals are asynchronous events by nature so special care must be taken in dealing
with them. Checking access with access(2)
then open(2)
is clearly non-atomic. Users can move files in between
the two calls. Instead, privileged applications should seteuid()
and then call open()
directly. Along the same lines, an application should always set a proper umask before
open()
to obviate the need for spurious chmod()
calls.
This, and other documents, can be downloaded from ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
For questions about FreeBSD, read the documentation before contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.