Skip to content

Harden native cancellation, inheritance, filesystem capabilities, and fault injection #3

Open

Description

@ORESoftware

Context

zed-lock v0.1.0 is published and independently certified on Linux, macOS, and Windows at commit 0fc100afc3cd60b5ce091b4207f910bf08f2cfb7.

This issue owns the remaining hardening work that was intentionally not claimed complete by the initial extraction.

Native backend work

  • Implement or document Windows overlapped LockFileEx completion and native cancellation semantics.
  • Certify descriptor/handle close-on-exec and non-inheritance behavior with child-process tests on all three platforms. Delivered by test: certify lock handles are not inherited across spawn #5; certified head 49f90fbc3de67d853a276e47c5df1ed4f2608826, merge f8add411c28c888a28abdcbc7fa9dcdb5ba0e745.
  • Add Windows path, case, junction, reparse-point, and handle-alias identity tests.
  • Expand macOS alias and process-inheritance tests beyond the current descriptor-release matrix.

Filesystem capability classification

  • Detect or explicitly classify local filesystems versus NFS, SMB, container bind mounts, and other shared-volume abstractions.
  • Return structured unsupported or degraded-capability errors where native exclusion cannot be guaranteed.
  • Document when an outer Fiducia lease plus fencing is mandatory.

Resource and ordering hardening

  • Add debug-time lock-order inversion detection across nested acquisitions. Delivered by Reject nested lock-order inversions before kernel waits #4, merge a0a0243911c190886397dad30ba68f50c321a93f.
  • Add waiter-budget exhaustion and cancellation tests with hundreds of independent identities.
  • Add deterministic long-running soak evidence and memory/thread accounting.
  • Ensure structured events never block or recursively deadlock the lock manager.

Fault injection

  • Kill owners and waiters at every open/acquire/metadata/write/release boundary.
  • Replace, rename, unlink, or permission-change lock paths while descriptors are open.
  • Add intentionally weakened variants to prove the tests detect overlapping critical sections and lost writes.
  • Verify ordinary local acquisition performs zero DNS/socket/HTTP/gRPC/Fiducia activity. Delivered by Prove local acquisition performs zero network syscalls #12, merge d65871b93fde8e7c9d5f5410bfa8f3543e42819a; the compiled example is executed under Linux strace -f -e trace=network after build and CI fails on any runtime network syscall.

Integration follow-through

  • Migrate remaining direct fs2 users in zed-cli where they belong behind this crate. Direct manifest-ownership cleanup is in zed-pkg/zed-cli#246; exact-head workflow certification remains pending.
  • Pin zed-cli to the standalone repository or released package without duplicating ownership between the workspace copy and this repository. Delivered by zed-pkg/zed-cli#198, merge 506106798e3fb3d23804f544dd41b020e9f7f8df.
  • Keep zed-pkg-test/concurrent-install-locking pinned to immutable released commits. The independent harness is pinned to the standalone immutable zed-lock revision and certified on Linux/macOS/Windows.

Tracking: zed-pkg/zed-cli#180, Linear DEN-2076, DEN-2046, and DEN-2042.

Activity

  1. self-assigned this
    on Aug 5, 2026
  2. ORESoftware commented on Aug 8, 2026

    @ORESoftware
    ContributorAuthor

    Shipped the lock-order hardening slice in #4, merged as a0a0243911c190886397dad30ba68f50c321a93f.

    What landed:

    • per-thread tracking of currently held lock order;
    • rejection of descending LockClass acquisition before any kernel wait;
    • canonical path ordering as the tie-break within one class;
    • RAII cleanup of the order registration before the Released event;
    • regression tests for Build -> Artifact inversion, descending same-class paths, and valid ascending ProjectMutation -> Artifact nesting.

    Validation:

    • pre-PR cargo fmt --all --check, all-target tests, and strict Clippy passed;
    • PR CI passed the complete Ubuntu 24.04, macOS 15, and Windows 2025 conformance matrices, including package/provenance contracts and negative cases.

    This completes the debug/runtime lock-order inversion detection item in this hardening issue. Native Windows cancellation, inheritance certification, NFS/SMB classification, deeper path aliases, expanded fault injection, and remaining direct-lock migrations stay open.

  3. ORESoftware commented on Aug 8, 2026

    @ORESoftware
    ContributorAuthor

    Descriptor/handle inheritance certification in progress

    Draft PR: #5
    Base: a0a0243911c190886397dad30ba68f50c321a93f
    Candidate: 31dc07c6949a4a80a5e2f6ec59041dc1cdec3a7e
    Changed path: tests/process_conformance.rs only

    The new process regression holds a real lock in the parent, starts a long-lived child that never opens the lock, drops the parent guard, and requires another process to acquire while the first child is still alive. This detects accidental lock descriptor/handle inheritance across Unix exec and Windows process spawn through the existing Ubuntu 24.04, macOS 15, and Windows Server 2025 matrix.

    The exact-head CI runs are active. No completion claim is made until all three platforms and the package job are terminal. The separate lower-level flag assertion (FD_CLOEXEC / HANDLE_FLAG_INHERIT) remains open if the behavioral test alone does not establish enough implementation evidence.

  4. ORESoftware commented on Aug 8, 2026

    @ORESoftware
    ContributorAuthor

    Remaining direct fs2 ownership cleanup opened in zed-cli

    Draft PR: zed-pkg/zed-cli#246
    Base: 1ab18fcb2ff884e82af4cac4513d7b983a23c84a
    Candidate: 866f79d74282022301c3b569e91af78be2cfcdfb
    Delta: Cargo.toml only, deleting direct fs2 = "0.4.3"

    The audit found LockWaiter is already re-exported from zed-lock, and project/store lock call sites already use LockManager/LockRequest. Repository search finds no remaining direct caller, and the checked-in lockfile contains no fs2 package entry. The full exact-head zed-cli workflow fleet is running to prove there is no hidden target- or platform-gated import.

    This is intentionally separate from the zed-lock pin update: the pin will move only after inheritance PR #5 is merged to immutable zed-lock/main. No source file or current inspect-protocol path is touched.

  5. ORESoftware commented on Aug 8, 2026

    @ORESoftware
    ContributorAuthor

    Permanent independent harness repinned to hardened zed-lock/main

    Test-org PR: zed-pkg-test/concurrent-install-locking#11
    Base: 2885593ded33b1c0fe355534ac49766afb71d0d2
    Candidate: 2dce3fa8f80516fac9d8f58e764da9524c3a1f61
    Exact delta: Cargo.toml only

    The independent harness previously pinned the initial extraction baseline 0fc100afc3cd60b5ce091b4207f910bf08f2cfb7. It now pins hardened merge f8add411c28c888a28abdcbc7fa9dcdb5ba0e745, incorporating both lock-order inversion rejection (#4) and descriptor/handle noninheritance certification (#5).

    Its permanent Ubuntu 24.04, macOS, and Windows thread/event/order/cancellation/process matrix and harness CI are queued on the exact candidate. This pin PR is independent of the separate zed-cli#246 source migration and does not change product code or test logic.

  6. ORESoftware commented on Aug 8, 2026

    @ORESoftware
    ContributorAuthor

    Permanent independent hardened pin merged

    zed-pkg-test/concurrent-install-locking#11 merged as dd617e3f374e15ac1083d5fd5f058212def54aa9 after exact candidate 2dce3fa8f80516fac9d8f58e764da9524c3a1f61 passed:

    • Harness CI 31269941669;
    • Ubuntu 24.04, macOS, and Windows locking matrix 31269941675;
    • formatting, dependency resolution, thread/event/ordering/cancellation/process tests, and strict Clippy.

    The permanent independent harness now pins hardened zed-lock@f8add411c28c888a28abdcbc7fa9dcdb5ba0e745, incorporating both lock-order inversion rejection (#4) and spawned-child descriptor/handle noninheritance certification (#5). The stale initial-extraction pin gap is closed.

  7. linear-code commented on Aug 8, 2026

    @linear-code
  8. ORESoftware commented on Aug 8, 2026

    @ORESoftware
    ContributorAuthor

    Follow-through split into focused trackers

    Two concrete gaps discovered during DEN-2076 integration are now independently tracked rather than hidden inside the umbrella:

    1. Secure rendezvous opening: Harden lock rendezvous creation: private permissions and symlink/reparse resistance #6 / Linear DEN-3091 owns private Unix modes/Windows ACLs, final-component symlink and reparse/junction refusal, race-resistant path opening, and structured unsafe-path errors. This is an unmet crate-level hardening contract. Review of zed-cli#246 found that the auth parent directory is already private on Unix, so no token-disclosure claim is being made; the library guarantee itself still needs to land.

    2. Windows copy-mode E2E portability: zed-pkg/zed-cli#252 / Linear issue created in the zed-pkg project owns four tests that unconditionally assert Unix symlink/live-source representation after the CLI correctly selects documented Windows copy mode. Independent certification now proves those exact failures against unmodified zed-cli/main before excluding only those names.

    The six-file zed-cli#246 migration remains draft and exact-head product CI is 24/24 green. Promotion is still serially held behind zed-cli#131 and zed-pkg-test/zed-pkg-e2e#49, followed by rebase and full recertification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions