Prev: Help creating a quote server simulator
Next: dynamically loading a shared library
From: Jonathan de Boyne Pollard on 11 Apr 2010 00:40
>
>
> Threads are not a UNIX concept. [...]
>
As I said elsewhere, you're overgeneralizing from Linux to Unix, here.

> Further, UNIX didn't offer the serialization mechanisms and APIs that
> IBM's OS and hardware supports (in enablement of threading, which is
> ancient and native there), so people didn't get experience with
> threading until much later and why "race conditions" are so common in
> UNIX and very uncommon in MVS.
>
No. It's not any lack of threading that causes these race conditions.
It is the historical API, but it isn't the API that deals in threading.
Many of the race conditions stem from API design that allows the rug to
be pulled out from under a process in between two system calls that it
makes as part of a larger task. One could stat() a directory to check
its ownership before using it, for example, but there was still the
unavoidable window of opportunity for the malicious between doing that
and then open()ing a file in that directory or chdir()ing into it.

Gradually, the handle-based design ethos has spread through much of the
Unix API, where it didn't exist originally. One now has the ability,
for example, to change working directory through a handle to a directory
that one opened earlier (fchdir()). On Linux, one can also open a file
within a directory via a handle to that directory rather than via a
pathname to it (openat()). But even now, as I recently noted in a post
elsewhere, there are still places where things are referenced by names
or by IDs in (the standardized) system API, where two successive system
calls using the same names/IDs have the potential to reference different
objects (which the malicious can switch around behind a process' back
for ill purpose), with no way around this. kill() with non-child
processes is a notable problem in this regard. It's still possible to
obtain a process ID (from somewhere) that is (unknown to the
application) then re-used by the system, before one can use it to signal
the process, causing one to signal an entirely different process, and
not the one intended.

None of this is affected by the presence or absence of threads, notice.

 | 
Pages: 1
Prev: Help creating a quote server simulator
Next: dynamically loading a shared library