mirror of
https://github.com/DeusData/codebase-memory-mcp.git
synced 2026-11-09 09:11:00 +08:00
Martin Vogel
d21e6cc762
Three maintainer decisions from the challenger read on the #1830 unit. 1. DELETE THE CACHE (not just fix its comment). posix_ancestor_overflow_uid() memoised via pthread_once behind a comment claiming "immutable /proc state". Both halves were false: unshare(CLONE_NEWUSER) rewrites /proc/self/uid_map, and pthread_once state survives fork() already marked done. A process that forked and then entered a namespace kept the parent verdict and refused a directory it should have accepted. It was harmless only because every caller today runs in a freshly exec'd process -- the daemon double-fork execs, workers go through cbm_subprocess_spawn's fork+exec, worker_pool.c never forks, and src/ contains no setns or unshare at all. That made a security decision depend on an invariant nothing enforced. The next fork-without-exec caller would have inherited a stale verdict silently. Now derived fresh per call: two small /proc reads against an openat + fstat + fchmod + ACL check per path component in the same walk. With a test that would have caught the original bug and needs no namespace. daemon_ipc_posix_overflow_uid_is_never_cached_issue1830 counts real derivations through the production entry point and asserts the count rises on every ancestor check. Re-introducing a cache fails it by name on every platform. Proven both ways on linux/arm64 as uid 1001: cache re-introduced 49 passed 1 failed; removed 50 passed 0 skipped. Worth knowing why that test is not redundant: with the re-exec probe in place, the userns smoke test PASSES even with the cache restored, because the probe is a fresh process and immune to it by construction. The two tests are complementary -- the smoke test binds the namespace wiring, this one binds the absence of the cache. 2. RUN THE GUARD ON THE CORE MATRIX. Ubuntu 23.10+ ships kernel.apparmor_restrict_unprivileged_userns=1, so the #1830 smoke test skipped on every 24.04 leg and its only real-namespace coverage sat on the two ubuntu-22.04 legs. Those are broad-matrix only, so the test ran in NO pull request, and GitHub retires those images on 2027-04-17 -- after which it would have become a permanent silent skip, and a skip is not a red. A deliberate relaxation of a security check was guarded by a test that ran nowhere a change would be reviewed, on a clock. _test.yml now lifts the restriction with one sysctl on every ubuntu leg (hosted runners have passwordless sudo), best-effort so a runner that refuses simply returns to skipping. The O10 skip-whitelist comment no longer presents the AppArmor restriction as immovable. 3. KEEP THE TOLERANCE, CORRECT THE SAFETY ARGUMENT. The comment claimed that in a single-uid map "nobody reachable can have created it or can mutate it". The overflow uid is what EVERY unmapped host uid maps to, not only host root (user_namespaces(7)), so overflow-owned does not prove root-created: on a shared host another local user's sticky directory is indistinguishable from root-owned /tmp from inside the namespace. The tolerance stays, because there is no in-namespace discriminator that could tell them apart -- and narrowing it would refuse the legitimate root-owned 01777 /tmp that #1830 exists to accept, i.e. it would revert the fix in practice. What changes is the claim: the real guarantee is that no principal reachable from inside the namespace can create or mutate such an ancestor, and the leaf is never tolerated as overflow (0700, euid-rechecked), so a hostile host-side ancestor owner is bounded to denial of service and socket-path control. macOS daemon_ipc 53 passed 2 skipped; linux/arm64 50 passed 0 skipped; lint-ci clean. Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>