[GH-ISSUE #2925] test(hopper): scope ordinary-user owner-exit verification to its launch #1029

New issue

Closed

opened 2026-10-15 18:30:28 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:30:28 +00:00

Owner

Originally created by @N0zoM1z0 on GitHub (Oct 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2925

Reproduction

Pinned main d4f0c5e664e26fe7ed1566dcc4b85ea9b57d52da, ordinary uid1004, isolated Ubuntu24.04.4 container with official free Hopper6.4.2, Node24.18.0:

node scripts/verify-real-hopper-linux.mjs

Real CLI/MCP provider queries proceed, then the owner-exit check fails after133.72s at scripts/lib/real-hopper-owner-exit.mjs:97:

process ownership token could not be read for2live process(es): environment_errno_EACCES=2; live candidates1=environment_errno_EACCES,7=environment_errno_EACCES

PIDs1/7 are unrelated root-owned docker-init/sleep processes that predate the verification launch. The same root-run full lane passes.

Owning boundary and correction

The caller has selected and identity-checked its MCP owner, but invokes verifyNoTokenOwnedProcesses(runId) globally. With no baseline/relation supplied, the existing inspector correctly remains conservative about all unreadable processes. This is a verifier-scope defect, not proof that the actual Hopper cleanup left children behind.

The owning API already accepts a captured PID/start-identity baseline and a relation as arguments3/4. Capture the appropriate baseline before the controlled MCP launch and pass it through the live-child negative control and post-exit proof. Preserve unknown for unreadable newly created/reused or plausibly related candidates; do not weaken the global default or ignore arbitrary EACCES.

Verify actual graceful and SIGKILL owner exit, subsequent same/different-target reacquisition, and unrelated-sentinel survival as the ordinary user. No new process protocol, global signals, foreign lock deletion or live-result cache is needed.

Separate observed condition

An intentionally elevated Hopper analysis leaves the vendor's root-owned /tmp/hopper-lockfile, blocking a later ordinary user. Independent setup-only verification does not create that lock. This issue uses a fresh ordinary-user provider context and concerns the ownership proof, not that upstream mixed-user lock condition.

Originally created by @N0zoM1z0 on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2925 ## Reproduction Pinned main `d4f0c5e664e26fe7ed1566dcc4b85ea9b57d52da`, ordinary uid1004, isolated Ubuntu24.04.4 container with official free Hopper6.4.2, Node24.18.0: ```sh node scripts/verify-real-hopper-linux.mjs ``` Real CLI/MCP provider queries proceed, then the owner-exit check fails after133.72s at `scripts/lib/real-hopper-owner-exit.mjs:97`: ```text process ownership token could not be read for2live process(es): environment_errno_EACCES=2; live candidates1=environment_errno_EACCES,7=environment_errno_EACCES ``` PIDs1/7 are unrelated root-owned docker-init/sleep processes that predate the verification launch. The same root-run full lane passes. ## Owning boundary and correction The caller has selected and identity-checked its MCP owner, but invokes `verifyNoTokenOwnedProcesses(runId)` globally. With no baseline/relation supplied, the existing inspector correctly remains conservative about all unreadable processes. This is a verifier-scope defect, not proof that the actual Hopper cleanup left children behind. The owning API already accepts a captured PID/start-identity baseline and a relation as arguments3/4. Capture the appropriate baseline **before** the controlled MCP launch and pass it through the live-child negative control and post-exit proof. Preserve unknown for unreadable newly created/reused or plausibly related candidates; do not weaken the global default or ignore arbitrary EACCES. Verify actual graceful and SIGKILL owner exit, subsequent same/different-target reacquisition, and unrelated-sentinel survival as the ordinary user. No new process protocol, global signals, foreign lock deletion or live-result cache is needed. ## Separate observed condition An intentionally elevated Hopper analysis leaves the vendor's root-owned `/tmp/hopper-lockfile`, blocking a later ordinary user. Independent setup-only verification does not create that lock. This issue uses a fresh ordinary-user provider context and concerns the ownership proof, not that upstream mixed-user lock condition.

bsakaguchi

2026-10-15 18:30:28 +00:00

closed this issue
added the
area: native

enhancement
labels

bsakaguchi commented

2026-10-15 18:30:29 +00:00

Author

Owner

@N0zoM1z0 commented on GitHub (Oct 14, 2026):

Verified resolved on current main419063043261b5342f46ad702f069009212e6ad3. The scope fix is already merged in eca18e08a: capture the pre-launch PID/start-identity baseline, observe the launched MCP owner group, and pass both through live and post-exit token inspections.

Fresh actual-provider verification, ordinary uid1004 in Ubuntu24, official free Linux Hopper6.4.2 demo, Node24.18.0/npm11.16.0:

node scripts/verify-real-hopper-linux.mjs

Full public CLI/MCP workflow passes, including graceful and identity-safe SIGKILL owner exits, same/different-target reacquisition, inventory/semantic/boundary cases, unrelated Hopper sentinel survival and verified empty final owned process lineage. Foreign root PIDs1/7 remain alive with environment EACCES, matching the original problematic host condition; no global ownership relaxation or foreign lock deletion was used.

All four source-built fixture digests remain unchanged, as do all3730trackedsource and1566runtime hashes. Wall 158.59s, waited-child CPU 145.51s, peak summed-family RSS estimate 1953.9MiB (100ms samples, shared host, may double-count shared pages). No agent-token or isolated speedup claim.

No duplicate source change is necessary. Raw report, source/runtime/fixture binding and ordinary-user permission evidence are retained under /tmp/rea-linux-e2e-d4f0c5e66/fix-2925/.

@N0zoM1z0 commented on GitHub (Oct 14, 2026): Verified resolved on current main419063043261b5342f46ad702f069009212e6ad3. The scope fix is already merged in eca18e08a: capture the pre-launch PID/start-identity baseline, observe the launched MCP owner group, and pass both through live and post-exit token inspections. Fresh actual-provider verification, ordinary uid1004 in Ubuntu24, official free Linux Hopper6.4.2 demo, Node24.18.0/npm11.16.0: ```sh node scripts/verify-real-hopper-linux.mjs ``` Full public CLI/MCP workflow passes, including graceful and identity-safe SIGKILL owner exits, same/different-target reacquisition, inventory/semantic/boundary cases, unrelated Hopper sentinel survival and verified empty final owned process lineage. Foreign root PIDs1/7 remain alive with environment EACCES, matching the original problematic host condition; no global ownership relaxation or foreign lock deletion was used. All four source-built fixture digests remain unchanged, as do all3730trackedsource and1566runtime hashes. Wall 158.59s, waited-child CPU 145.51s, peak summed-family RSS estimate 1953.9MiB (100ms samples, shared host, may double-count shared pages). No agent-token or isolated speedup claim. No duplicate source change is necessary. Raw report, source/runtime/fixture binding and ordinary-user permission evidence are retained under `/tmp/rea-linux-e2e-d4f0c5e66/fix-2925/`.

bsakaguchi referenced this issue

2026-10-17 21:07:58 +00:00

[PR #1029] [MERGED] fix(domain): reject excessive JSON depth with actionable diagnostics #2593

bsakaguchi referenced this issue

2026-10-17 21:08:16 +00:00

[PR #1068] [MERGED] fix(cli): preserve blank JSON paths for input validation #2617

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-10-31 00:29:51 +00:00