Checking for Race Conditions in File Accesses.¶
Bishop, M., & Dilger, M. (1996). Checking for Race Conditions in File Accesses. Computing Systems, 9(2), 131-152.
Cited by¶
5 citations across 5 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Time-Of-Check To Time-Of-Use Flaw
- It executes
access(path)at time \(t_1\), which consults the filesystem state \(S\) — the inode that Path resolves to — and returns "permitted."This sourceFoundational analysis of the access/open TOCTOU file-access race in Unix and the descriptor-versus-path remedy.
- It executes
- Unverified Precondition
- The action site (role). A locus that will operate on some referenced entity at the moment of commit. The referenced entity (role). An object, capability, counterparty, channel, or resource whose existence-and-availability is the precondition for the action's success. The trust posture (relation). No explicit check at the action site that the referent currently exists — the action presumes the reference resolves. The existence dimension (invariant). Existence — is it there at all? — is a load-bearing precondition separate from any value property (correctness, freshness, schema-conformance, authority); the action's logic is correct given existence, and blind to the existence question itself. The failure surface (relation). When the presumption fails, the action crashes or proceeds with an absence treated as a presence, surfacing downstream far from the missing existence. The site-and-moment invariant. Existence must be verified here and now: verification at the planning site or at an earlier time does not establish existence at the action site at commit — the time-of-check-to-time-of-use gap is the time-window-sensitive instance.
This sourceNames and analyzes the time-of-check-to-time-of-use (TOCTOU) race, where a referent verified at check time is gone or altered by use time — the time-window-sensitive instance of an unverified existence precondition.
- The action site (role). A locus that will operate on some referenced entity at the moment of commit. The referenced entity (role). An object, capability, counterparty, channel, or resource whose existence-and-availability is the precondition for the action's success. The trust posture (relation). No explicit check at the action site that the referent currently exists — the action presumes the reference resolves. The existence dimension (invariant). Existence — is it there at all? — is a load-bearing precondition separate from any value property (correctness, freshness, schema-conformance, authority); the action's logic is correct given existence, and blind to the existence question itself. The failure surface (relation). When the presumption fails, the action crashes or proceeds with an absence treated as a presence, surfacing downstream far from the missing existence. The site-and-moment invariant. Existence must be verified here and now: verification at the planning site or at an earlier time does not establish existence at the action site at commit — the time-of-check-to-time-of-use gap is the time-window-sensitive instance.
Mechanisms¶
- Dry-Run Reclamation Report
- A manifest is a snapshot; if the reference graph changes between preview and execution, an approved delete can operate on stale reality and remove something that became reachable in the interim — a classic time-of-check-to-time-of-use hazard.
This sourceDefines a time-of-check-to-time-of-use race in which an object binding changes after a security check but before the checked object is used, making the earlier result stale.
- A manifest is a snapshot; if the reference graph changes between preview and execution, an approved delete can operate on stale reality and remove something that became reachable in the interim — a classic time-of-check-to-time-of-use hazard.
- Just-in-Time Existence Check
- Between the last observation and the action there remains a gap — the classic time-of-check to time-of-use window — into which a fast or hostile change can still slip.
This sourceFormalizes file-access races in which an attacker changes state between a security check and the subsequent use of its result.
- Between the last observation and the action there remains a gap — the classic time-of-check to time-of-use window — into which a fast or hostile change can still slip.
- Refresh Validity Probe
- Its central failure mode is time-of-check to time-of-use: a state confirmed valid at the probe can lapse before the action it authorized runs, so a verdict is only as good as how promptly it is used.
This sourceAnalyzes time-of-check-to-time-of-use races in which a file-system state can change after validation but before the validated operation occurs.
- Its central failure mode is time-of-check to time-of-use: a state confirmed valid at the probe can lapse before the action it authorized runs, so a verdict is only as good as how promptly it is used.
Verification¶
Does it exist? Not checked yet. This entry carries no identifier to resolve. It was extracted from the citation as written in the article, normalized, and deduplicated against the rest of the registry.
Does it back the claim? Not recorded. Neither this nor any other of the 5 citations of this work carries a recorded support check.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Links previously used in the corpus¶
Before the registry existed this work was also linked 1 other way.
Registry ID ref:516859156078 · see in the full table