install-local routes accept any authenticated session (plus an x-user-id header fallback) — a schema-mutating channel with no capability check, cross-tenant on walled multi-org deployments

[os-zhuang]

Cross-repo filing from the repo:cloud whole-repo seat (objectstack#6026, session session_0137TnZzVmkSjXxoSVgPFS6S, 2026-08-16), surfaced by a deployment survey for the walled-posture EE SaaS shape (cloud#1331). Fix lands in this repo (packages/cloud-connection), hence filed here per the issues-live-where-the-fix-lands rule. Unassigned — domain:* routing belongs to the triage seat (the lane table maps packages/cloud-connection to domain:cli; taking that as a suggestion, not a label).

Measured (framework origin/main; consumer context at cloud origin/main)

packages/cloud-connection/src/marketplace-install-local-plugin.ts:1320-1341 — requireAuthenticatedUser accepts any better-auth session, and falls back to trusting a bare x-user-id request header (:1338). It is the only check on:

• POST /api/v1/marketplace/install-local (:454) — accepts an inline manifest, hot-registers its objects into the shared registry (:646-651), runs ql.syncSchemas() against the shared database (:694-702), writes the install ledger (:681-688), runs seed data (:709);
• DELETE …/install-local/:id (:780), …/reseed-sample-data, …/purge-sample-data.

No capability is consulted on any of them. For comparison, the platform's other metadata-write doors are gated: PUT /api/v1/meta/:type/:name requires manage_metadata (#6603; packages/rest/src/meta-item-save-capability-gate.test.ts), and POST /api/v1/ai/tools/:toolName/execute requires manage_metadata or studio.access. This route is the odd one out — declared as an operator-grade action, enforced as "anyone with a login".

Two test files look like they cover this and do not: marketplace-install-local-posture-gate.test.ts is the ADR-0120 D5e confirmation ceremony for installation-wide unique indexes — and the caller satisfies it themselves by passing confirmGlobalUniques in their own request body (:634-637); marketplace-install-local-tenancy-posture.test.ts selects the seeding path, not authorization.

Why it matters, by deployment shape

• Walled multi-org EE deployment (one shared DB, orgs = customers — the cloud#1331 SaaS shape): any signed-up user of any customer org can install/uninstall packages, i.e. mutate the schema every tenant runs on. Metadata is environment-scoped, not org-scoped, so the Layer 0 tenant wall does not reach these writes — this is a cross-tenant write channel. It also defeats the cloud-side maintainer ruling that AI build must be structurally closed on that shape (closing the build agent while this route stays open closes the front door and leaves the loading dock unlocked).
• Single-org self-host: severity is lower (all users are one tenant's), but "any employee with a login can alter the schema and run seed data" still contradicts the operator-action framing, and the x-user-id fallback means an unauthenticated caller who can reach the port can pass the check where no session store is consulted first.

Suggested direction (dev/triage judgement, not a ruling)

Require a real capability (manage_metadata, matching the /meta precedent) on all four routes, service/operator tokens exempt as elsewhere; scrutinize the x-user-id fallback separately — if it exists for a dev-mode reason, gate it to that mode explicitly. A two-principal test (capability holder 2xx, plain member 403, header-only caller 401/403) pins the class. Note the mount itself is deliberately unconditional on the EE image (cloud#1287 moved it out of the marketplaceUrl ternary so air-gapped boxes stop 404ing) — the fix here is authorization on the routes, not un-mounting the plugin; whether walled deployments should additionally be able to disable it is cloud-side and tracked under cloud#1331.

Re-check commands:

git grep -n "requireAuthenticatedUser" -- packages/cloud-connection/src/marketplace-install-local-plugin.ts
git grep -n "x-user-id" -- packages/cloud-connection/src
git grep -rn "manage_metadata" -- packages/rest/src | head -5 # the precedent gate

Refs: cloud#1331 (deployment context + survey record), cloud#1344 (the AI-agents half of the same "close every metadata-write channel" ruling), cloud#1338 (the harness that will assert this refusal).

[os-project-manager]

Triage: pm:queue + domain:cli (lands in packages/cloud-connection, per the lane table) + security + target:v17, type Bug (filer's prefill stands). Release-board rationale (binary test, class ②): declared-≠-enforced on a published schema-mutating surface — an operator-grade action enforced as "anyone with a login", cross-tenant on the walled multi-org shape; same class as #8919 (REST /meta publish/rollback doors), which already sits on the v17 board.

Not escalated: the fix tightens enforcement to the declared operator-grade framing following the established manage_metadata precedent (#6603, service/operator tokens exempt as elsewhere) — a declared=enforced restoration, not a product decision. In-card dev judgment: scrutinize the x-user-id fallback separately (gate to dev mode explicitly if that is its reason); ⛔ do not un-mount the plugin (cloud#1287's unconditional mount is deliberate). Two-principal test pins the class.

Size/model suggestion: M, opus.

本评论来自分诊座位 Routine。

---

Generated by Claude Code

[qq9340100]

Claim: PM loop round 17
Session: session_01NaS1PAHJcPfAA2acnV53Tn
Branch: claude/issue-8976-install-local-capability-gate
Worktree: objectstack-issue-8976
Domain: domain:cli
File surface: packages/cloud-connection/src/** — the four install-local routes, requireAuthenticatedUser, and a new two-principal pin (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus (as triage suggested)
Serial constraints cleared: no open PR touches packages/cloud-connection. ⚠️ #8857 (#8645) landed in this package earlier today — it made MarketplaceProxyPlugin a module-scope declaration so esbuild stops renaming it. Different file, but re-read the merged ref rather than the card's picture of it.

Dispatched under the maintainer's direct channel (「继续」, 2026-08-16), single-card batch — this is the top of the lane ordering: target:v17 + security.

⛔ Not re-graded. Triage ruled it not escalated and the reasoning is binding: the fix tightens enforcement to the declared operator-grade framing, following the manage_metadata precedent (#6603, service/operator tokens exempt as elsewhere). That is a declared = enforced restoration, not a product decision.

Why this sits above everything else in the lane

It is the same family as #8919, which I landed hours ago (PR #8977) — but a layer deeper. #8919 was "promote a draft somebody else wrote". This is ql.syncSchemas() against the shared database, plus hot-registering objects from an inline manifest, plus writing the install ledger and running seed data — behind a check that only asks whether you are logged in.

Metadata is environment-scoped rather than org-scoped, so Layer 0's tenant wall does not reach these writes: on the walled multi-org EE shape this is a cross-tenant write channel. The filer's framing is exact and worth keeping in the changeset — closing the AI build agent while this route stays open "closes the front door and leaves the loading dock unlocked."

⭐ Two existing test files look like coverage and are not. marketplace-install-local-posture-gate.test.ts is the ADR-0120 D5e confirmation ceremony — and the caller satisfies it themselves by passing confirmGlobalUniques in their own request body. marketplace-install-local-tenancy-posture.test.ts selects the seeding path, not authorization. Do not read either as evidence the door is guarded.

裁决(不可重裁)

1. Require a real capability on all four routes — manage_metadata, matching the /meta precedent; service/operator tokens exempt as elsewhere. Copy the established idiom rather than inventing one.
2. ⛔ Do NOT un-mount the plugin. cloud#1287 deliberately moved the mount out of the marketplaceUrl ternary so air-gapped boxes stop 404ing. The fix is authorization on the routes. Whether walled deployments should additionally be able to disable it is cloud-side, tracked under cloud#1331 — ⛔ not yours.
3. A two-principal pin is required, not optional: capability holder → 2xx; plain authenticated member → 403; header-only caller → 401/403. That is what pins the class rather than the two symptoms.

The x-user-id fallback is a SEPARATE judgement — do not fold it in silently

requireAuthenticatedUser falls back to trusting a bare x-user-id request header. The filer's reading, which I am passing on as a reading rather than a fact: on a path where no session store is consulted first, that lets an unauthenticated caller who can reach the port pass the check.

Measure what that fallback actually does before touching it. If it exists for a dev-mode reason, gate it explicitly to that mode. If removing it breaks a legitimate caller, stop and report — that is a different decision from adding the capability gate, and it should not ride along unexamined. Report the two outcomes separately in your report.

PM 机制假设(须实测,鼓励证伪)

Reachability first, as with #8919. Drive the three principal shapes through a composed host to the point where the schema actually mutates — do not infer exploitability from the check's shape. If something downstream already refuses, that is a complete delivery: premise_still_valid: false + pr: null.

⚠️ The card cites line numbers (:1320-1341, :454, :646-651, :694-702, :681-688, :709, :780, :1338). Re-locate every one by symbol. Line numbers in this repo have been stale within hours all week.

Precedent to reuse

#8919 / PR #8977 landed today and is the template. It gated two /meta doors on the sibling doors' verbatim idiom and added meta-write-door-capability-enumeration.test.ts, whose load-bearing assertion derives every mutating route from the composed server's own route table and compares it to a declared list — so a new ungated door fails the build. Read that test before writing yours; if the same anti-drift shape fits this route family, use it.

Gates

Derive with node scripts/pm/dispatch-gates.mjs <actual changed paths> after your final commit and run the union. ⚠️ The derivation's silence is not evidence of absence (#8889). Expect check:authz-resolver to be in scope. Redirect gate output to files; never pipe it. A gate that refuses to run is NOT MEASURED.

Reverse-verify with the direction predicted in writing first: with the gates reverted, the refusal cases go red and the capability-holder control stays green.

---

Generated by Claude Code

[qq9340100]

{
 "issue": 8976,
 "status": "done",
 "branch": "claude/issue-8976-install-local-capability-gate",
 "pr": "https://github.com/objectstack-ai/objectstack/pull/9012",
 "premise_still_valid": true,
 "summary": "REACHABILITY FIRST: three principal shapes driven through the composed plugin to the point the state actually changes (manifest.register, objectql.syncSchemas, the ledger file on disk, SeedLoaderService.load, driver.delete). All three were indistinguishable — 200 on all four routes, every effect fired, nothing downstream refused: header-only (bare x-user-id, NO session) install/reseed/purge/uninstall = 200/200/200/200 with installedBy recorded as 'attacker'; authenticated-without-capability = identical; capable control = identical. The card's line numbers were re-located by symbol and were all still accurate on origin/main. OUTCOME 1 (capability gate): the four mutating routes now resolve identity AND capability via resolveAuthzContext (the platform's single authz resolver, the same move plugin-sharing and service-settings made for this exact bug) and demand manage_metadata — 401 with no principal, 403 FORBIDDEN naming the capability without it, refusal issued before any work. Service/operator tokens are exempt with no special case: an API key resolves through the same resolver to its owner's real grants. Mount left unconditional per cloud#1287. OUTCOME 2 (x-user-id fallback): REMOVED, not mode-gated — see open_questions for the reasoning and the evidence that no legitimate caller breaks. Adds marketplace-install-local-capability-enumeration.test.ts (route list derived from the plugin's own route table, #8919 shape) and annotates the two misleading suites without weakening either.",
 "tests": "Union derived AFTER the final commit (node scripts/pm/dispatch-gates.mjs over the actual changed paths) and run at HEAD 5e9f95925 — all EXIT=0: check:nul-bytes, check:authz-resolver, check:changeset-gate-self-tests, check:objectui-changeset, check:query-options-erasure, check:engine-double-contract, check:where-matcher, check:type-check-coverage, check:type-check-debt (--re-measure, on a closure built with `turbo run build --filter=./packages/* --filter=./packages/*/*`, 70/70 tasks), check:cross-package-test-inputs, check:published-files, check-adr-0087-registration, check-changeset-no-major, check-empty-changeset. Output redirected to files, never piped. check:authz-resolver was NOT named by the derivation (PM predicted it; the derivation's silence is not absence) and it passes. check:cross-package-test-inputs and check:published-files were also added beyond the derived list because the diff introduces a shared in-package fixture module — both pass. `pnpm --filter @objectstack/cloud-connection test`: 'Test Files 20 passed (20) / Tests 159 passed (159)'. One red lap along the way, fixed rather than ledgered: check:type-check-debt measured '@objectstack/cloud-connection: DEBT records 13 raw tsc error(s), tsc --noEmit now reports 14 (+1)' from a TS2345 union-widening in the new pin; annotating the headers literal returned the package to 13 (author's remedy; raising the entry is maintainer-only). REVERSE VERIFICATION with the direction written down before running (prediction file: 12 refusal cases red, controls green, and the installedBy case predicted GREEN because the old code consulted the session before the header): restored marketplace-install-local-plugin.ts from origin/main with every test at the fixed state — observed 'Tests 12 failed | 147 passed (159)', the 12 being exactly the 4 doors × {header-only 401, plain member 403, tenant org-admin 403}; all four capability-holder controls, both enumeration assertions, the installedBy case and all 13 re-fixtured suites stayed green. Fix restored from the commit (git checkout HEAD -- path), tree verified clean. No dogfood ablation in this diff, so no dist rebuild applies.",
 "open_questions": [
 {
 "question": "The x-user-id fallback — reported as a SEPARATE outcome per the dispatch. Measured, then removed rather than mode-gated. Flagging the judgement rather than asking permission retroactively: it is reversible in one commit if the PM disagrees.",
 "options": [
 "A — remove it (taken): measured that it admits an unauthenticated caller straight to syncSchemas() against the shared database, with installedBy recorded as a caller-chosen string. Its comment claims a dev-mode reason but there is NO mode flag on it to gate to — it fires on any request where no session resolves, in every deployment. It was the last x-user-id trust left in packages/** source; the two sibling raw-route surfaces that carried the identical line (plugin-sharing share-link routes, service-settings settings routes) both removed it in favour of resolveAuthzContext rather than restricting it. The one first-party caller, `os package install`, signs in for a real better-auth cookie and never sent the header (packages/cli/src/commands/package/install.ts). No legitimate caller was found that this breaks.",
 "B — gate it to a dev mode: needs a mode signal that does not exist on this path, and would keep a production admission path alive behind a flag whose default nobody audits — the shape the two sibling fixes explicitly rejected.",
 "C — leave it and rely on the capability gate alone: does NOT work. The gate reads systemPermissions off the resolved principal; a header-derived userId would resolve no grants and be refused 403, so the header becomes dead weight that still reads as a supported identity path to the next author."
 ],
 "recommendation": "A, taken. Real business need: no measured consumer — the CLI, the console and the cloud control plane all use sessions or API keys. Long-term soundness: it is the third instance of a settled pattern, not a new one, and it removes the last copy of a class this repo has now paid for three times. AI-code safety: a header that names a user without proving one is exactly the surface an AI-authored integration copies from a neighbouring file; deleting it removes the thing to copy."
 },
 {
 "question": "Structural fix for the two misleading suites: docblock disclaimer versus rename. The dispatch asked for the argument either way.",
 "options": [
 "A — annotate, do not rename (taken): both files now OPEN with an explicit '⛔ THIS FILE IS NOT AN AUTHORIZATION TEST' block stating what they do not cover and naming marketplace-install-local-capability-enumeration.test.ts, plus a final describe that ASSERTS that file exists — so the pointer cannot rot into a confident wrong answer if the pin is ever renamed or deleted. Neither test weakened or deleted.",
 "B — rename them (e.g. …-global-unique-ceremony.test.ts, …-seed-path-selection.test.ts): mechanically safe, nothing outside the two files references either name."
 ],
 "recommendation": "A. Both names are ACCURATE about their own subjects — 'posture-gate' really is a posture-scoped gate (ADR-0120 D5e), 'tenancy-posture' really does test the tenancy posture; the misreading came from the reader, and the next accurate-but-adjacent name would mislead the same auditor. The real defect was that NO file answered 'is install-local gated?', which is now answered by a file whose name IS the question — that is the structural fix, and it is what a grep for capability/authorization finds first. A rename would additionally cost blame continuity on two suites carrying dense incident-derived commentary (#5426, #5262, ADR-0120) and buys nothing the executable disclaimer does not. Cheap to reverse if the PM prefers B."
 }
 ],
 "out_of_scope_findings": [
 "filed as #9011: GET /api/v1/marketplace/install-local (handleList) runs NO identity resolution at all — an anonymous caller receives the installed-package inventory, the installedBy user ids and the host's absolute storageDir. Not folded in: the 裁决 names the four mutating doors, and which posture the READ should take is a real decision (authenticated floor / the same manage_metadata / field narrowing) that interacts with #6721's reason for putting storageDir in that payload. Searched by keyword and by file path over open issues before filing; no duplicate. Unassigned, unlabeled for PM triage (concrete defect, not observation-class). The new enumeration pin deliberately excludes the GET and says so in a comment, with a companion assertion that the GET is still mounted so the exclusion cannot become an accidentally empty filter."
 ]
}

Generated by Claude Code

---

Generated by Claude Code