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 http://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>.