Skip to content

test(rig-lock): open the lock read-only so a non-root reserve can't EACCES the root gate (#242) - #245

Merged
VijitSingh97 merged 1 commit into
developfrom
claude/rig-lock-readfd-242
Jul 12, 2026
Merged

VijitSingh97 merged 1 commit into
developfrom
claude/rig-lock-readfd-242

Conversation

@VijitSingh97

Copy link
Copy Markdown
Contributor

Closes #242. Hit live during the v1.7.0 rollout: a manual non-root flock reserve created /run/lock/rig-e2e.lock owned by that user, and with fs.protected_regular=2 (Ubuntu default) the root e2e-real.sh rig_lock's exec 9> (O_CREAT-write) then failed with EACCES — aborting the perf gate until the file was rmed.

Fix: open the lock read-only (exec 9<). Read-opens aren't protected_regular-guarded and flock -x/-s works fine on a read fd, so this sidesteps the block without ever rm-ing a possibly-held lock (the tmpfiles pre-create the issue floated would have added clutter to every production rig; this doesn't). Applied identically to e2e-real.sh and e2e-pithead.sh (the #183 drift guard keeps them in lockstep). The ~/README.md box contracts already updated to reserve-as-root as belt-and-suspenders.

Verification: 2 new sandbox tests (pre-existing file; restrictive-mode file); all 11 existing #183 lock tests still green; and a live root repro on miner-3 — a vijit-created lock file: old 9> → EACCES, new 9< → ACQUIRED. Local gate: 1227 passed / 0 failed, lint + lint-md green.

@VijitSingh97
VijitSingh97 enabled auto-merge (squash) July 12, 2026 01:24
…ACCES the root gate (#242)

/var/lock -> /run/lock is a sticky world-writable tmpfs with
fs.protected_regular=2. A lock file first created by a NON-root flock
(a manual reserve after a reboot clears the tmpfs) is owned by that
user, and protected_regular then blocks even root's O_CREAT-write
(exec 9>) of it with EACCES — the release perf gate aborted with
'Permission denied' until the file was rm'd (hit live during the
v1.7.0 rollout). Open the lock read-only (exec 9<) instead: a read-open
is never protected_regular-guarded and flock -x/-s works on a read fd,
so this sidesteps it without rm-ing a possibly-held lock. Applied to
both e2e-real.sh and e2e-pithead.sh (drift guard keeps them identical);
2 new tests; live-verified on miner-3 (vijit-created lock: old 9>
EACCES, new 9< ACQUIRED).

Closes #242

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@VijitSingh97
VijitSingh97 force-pushed the claude/rig-lock-readfd-242 branch from c85f074 to 7e31500 Compare July 12, 2026 01:25
@VijitSingh97
VijitSingh97 merged commit a950445 into develop Jul 12, 2026
9 checks passed
@VijitSingh97
VijitSingh97 deleted the claude/rig-lock-readfd-242 branch July 12, 2026 01:28
VijitSingh97 added a commit that referenced this pull request Jul 13, 2026
…ACCES the root gate (#242) (#245)

/var/lock -> /run/lock is a sticky world-writable tmpfs with
fs.protected_regular=2. A lock file first created by a NON-root flock
(a manual reserve after a reboot clears the tmpfs) is owned by that
user, and protected_regular then blocks even root's O_CREAT-write
(exec 9>) of it with EACCES — the release perf gate aborted with
'Permission denied' until the file was rm'd (hit live during the
v1.7.0 rollout). Open the lock read-only (exec 9<) instead: a read-open
is never protected_regular-guarded and flock -x/-s works on a read fd,
so this sidesteps it without rm-ing a possibly-held lock. Applied to
both e2e-real.sh and e2e-pithead.sh (drift guard keeps them identical);
2 new tests; live-verified on miner-3 (vijit-created lock: old 9>
EACCES, new 9< ACQUIRED).

Closes #242

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

rig-lock: pre-create /var/lock/rig-e2e.lock world-writable so a non-root reserve can't lock out the root e2e rig_lock

1 participant