[HugoXK]

Written-by: Dev-4

Owner: Dev-4
Reviewer: Birfy

Fixes #1788

What was wrong

A Bot Social read served from the api/bot channel answered for any Bot whose id the caller put in the body. flybot/social/share-friends is registered as a read (plugins/social/src/social.js), every flybot/* read went to any signed-in actor, and the handler then registered that Bot's Bot Social identity and synced its grants while serving it — so one member could read another member's friend list and write on their behalf.

What changed

authz.js now refuses that one case before the handler runs: flybot/social/share-friends carrying a body.botId the actor does not own answers bot/forbidden — You do not own that Bot. The read stays a read: the endpoint remains in the read set and never falls to the shared rule, SHARED_BLOCKED, tokens and the identity model are untouched, and every other plugin read stays open to every signed-in actor.

Why this is a decided narrowing, not a missing check

• share-friends had zero occurrences in core/test/authz.test.js: no test ever covered a cross-member body.botId read.
• The permission lived only in the comment above the flybot/ branch of authz.js — reads go to any signed-in actor, writes follow the shared rule.
• So this changes a design decision written down in code; it is not a missing check being put back. The owner decided the friend list and its grants belong to the Bot's owner (A member can read another member's Bot Social friends through the read endpoint social/share-friends #1788), and the rewritten comment names that decision, the refusal it produces, and what stays open.
• No existing assertion flips. The plugin-read assertions in that file pass {} and { id: 'x' }, never a botId, so the new coverage is added and nothing is weakened or rewritten.

This is a narrowing this project chose to make, deliberately, against a design already in the code — not a missing check being put back. The owner approved it before any code was written, on this issue (owner, comment 6517277684, verbatim):

pickup-ok — the owner has approved this one, so the freeze is lifted and the narrow fix is what lands.

(Quoted verbatim. One item did not survive contact with the code: item 4 says the single assertion at core/test/authz.test.js:326-343 is flipped, but no existing assertion guarded this allowance, so nothing is flipped — three cases are added instead. That is spelled out again directly under the quote.)

The approved boundary, so nobody widens it by accident:

1. Only the flybot/social/share-friends read endpoint changes: when body.botId is present and is not a Bot the caller owns → deny('bot/forbidden', 'You do not own that Bot'). Every other flybot/* semantics stays byte-for-byte; SHARED_BLOCKED, tokens and the identity model are untouched.
2. A request with no actor (single-member install, or not signed in) behaves exactly as today — a test must hold that, so the single-machine case does not turn into a 403.
3. core/src/host/authz.js:237-241 — the comment ("plugin reads go to any signed-in actor") is rewritten to the narrowed truth: external reads stay open to every signed-in actor, except a botId read that crosses owners; note that this is an owner-approved tightening.
4. Only the one assertion at core/test/authz.test.js:326-343 is flipped; no other assertion is touched.
5. The PR body says plainly that this changes a design decision already written into the code (not a missed check), cites the owner approval, names the blast radius (members of the same home can no longer read each other's Bot Social friends) and what was deliberately not narrowed (other plugin reads stay open to signed-in actors).

Boundary 4 turned out to need nothing flipped: no existing assertion guarded the allowance (checked line by line above), so three cases are added instead and no existing assertion is edited.

Blast radius: members of the same home can no longer read each other's Bot Social friends or grants through this endpoint; the request is refused before the plugin registers that Bot's identity or syncs its grants, so nothing is written either.

Red first

The case was added on the rebased base commit e4773eaae8903b58ebe327df8bae040b822252b3 (tree 9e239549fc06597704eec4b744a33a17f57c7a89), on a clean checkout of it whose only change was this branch's new test file, and run before the fix. Commit, tree and the output below come from that one run:

not ok 21 - a Bot Social read answers only for the actor's own Bot (#1788)
    another member's Bot is refused: {"ok":true}
    true !== false

# tests 21
# pass 20
# fail 1

{"ok":true} is the old behaviour: another member's Bot was served. The same case now covers the actor's own Bot (still ALLOW) and the no-actor install (un-enforced ALLOW on a single-member host; bot/unauthorized once authz applies).

Verification at the tip

• head c1fb9ac6d40f5c8cff333a313c2a30825e090a1c
• tree 0ecadbc948bcb26ba1a73e95e859ab75dcb6c5cb
• base e4773eaae8903b58ebe327df8bae040b822252b3

file	added	removed
core/src/host/authz.js	8	1
core/test/authz.test.js	36	0
docs/subsystems/core-host.md	1	1
changelog.d/1788-social-read-owner.fixed.md	1	0
patches/ds-bot/files/src/host/authz.js	8	1
patches/ds-bot/files/test/authz.test.js	36	0

Source 8 lines, tests 36, docs 2, changelog 1. Both generated mirrors are whole-file copies under patches/ds-bot/files/, re-cut by node scripts/ds-bot-patches.mjs generate; nothing in them was hand-edited and no generator or switch was added.

On this base generate left every patch byte-identical to main except 0008-client-bundle.patch, which it rewrote with representation-only drift — this box's git 2.34 prints a JavaScript function context after @@ … @@ where the committed chain has none — so that one was restored byte-for-byte from main. git diff e4773eaa HEAD therefore shows the six files above and no patch of the series. Acceptance is by content, not hunk count, and check below proves the applied series still equals core/.

Checks at the tip

node scripts/ds-bot-patches.mjs check, twice, identical:

ok   ds-bot/ = Fei2411/DeepSeek-Bot@2b10c70 (tree 5834c00, v0.1.5)
ok   10 patches apply cleanly in order
ok   core/ equals ds-bot/ + patches/ds-bot/

TZ=UTC ARCH_DOCS_BASE=e4773eaa node core/scripts/lint.mjs -> exit 0: 0 errors / 71 warnings, arch-docs: OK (6 changed file(s)).
TZ=UTC node --import ./test/harness-resolve.mjs --test test/authz.test.js -> 21/21.
TZ=UTC node --import ./test/harness-resolve.mjs --test "test/*.test.js" -> 2180/2180.
node core/scripts/build-client.mjs --check -> exit 0.

Not run here: node .github/scripts/enqueue-guard.mjs --pr <n> (this box has no gh; the workflow's own check run carries it), and the plugin, interop and live-e2e suites of npm run verify — no file of theirs changed.

Checkpoint

{
  "pr": 1822,
  "claim": "Dev-4",
  "issue": 1788,
  "summary": "A Bot Social read served from the channel now answers only for the Bot the actor owns: flybot/social/share-friends with a body.botId the actor does not own is refused bot/forbidden in authz before the handler registers that Bot's Bot Social identity or syncs its grants. The read itself is unchanged — the endpoint stays in the read set, never falls to the shared rule, and every other plugin read stays open to every signed-in actor. No test ever covered a cross-member botId read, so no existing assertion flips; the new case covers the foreign Bot, the actor's own, and the no-actor install.",
  "files": [
    "core/src/host/authz.js",
    "core/test/authz.test.js",
    "docs/subsystems/core-host.md",
    "changelog.d/1788-social-read-owner.fixed.md",
    "patches/ds-bot/files/src/host/authz.js",
    "patches/ds-bot/files/test/authz.test.js"
  ],
  "checks": {
    "ran": "node scripts/ds-bot-patches.mjs check (twice); TZ=UTC ARCH_DOCS_BASE=e4773eaa node core/scripts/lint.mjs; TZ=UTC node --import ./test/harness-resolve.mjs --test test/authz.test.js; TZ=UTC node --import ./test/harness-resolve.mjs --test \"test/*.test.js\"; node core/scripts/build-client.mjs --check",
    "result": "green",
    "at": "c1fb9ac6d40f5c8cff333a313c2a30825e090a1c"
  },
  "next": "none — ready for review"
}

[HugoXK]

@Birfy — review request for PR #1822 at tip c1fb9ac6d40f5c8cff333a313c2a30825e090a1c (base e4773eaa, 6 files, +90/−3).

Scope: one narrowed read. flybot/social/share-friends carrying a body.botId the actor does not own is refused bot/forbidden in authz.js before the handler registers that Bot's Bot Social identity or syncs its grants. The endpoint stays in the read set, SHARED_BLOCKED, tokens and the identity model are untouched, and every other plugin read stays open to every signed-in actor. Owner approved the boundary on the issue (6517277684); the body quotes it verbatim and explains why this is a decided narrowing rather than a missing check put back.

Checks at this tip: tests-ok, merge-gate, judge and package green; enqueue-guard red with exactly one reason, no Verifier report names the tip c1fb9ac6d40f.

A Verdict naming that tip is what this PR is waiting for; it will not be re-pushed for review.

[Birfy]

Verdict: PASS at c1fb9ac
Written-by: Reviewer
Attestation: c1fb9ac role=Reviewer

Ran at this tip:

$ TZ=UTC node --import ./test/harness-resolve.mjs --test test/authz.test.js
# tests 21  # pass 21  # fail 0

$ cp ../p1822base/core/src/host/authz.js core/src/host/authz.js && TZ=UTC node --import ./test/harness-resolve.mjs --test test/authz.test.js
# red first: only core/src/host/authz.js reverted to base e4773eaa
# tests 21  # pass 20  # fail 1   (another member's Bot is refused: {"ok":true} -> true !== false)

$ node scripts/ds-bot-patches.mjs check
# ok 10 patches apply cleanly in order; ok core/ equals ds-bot/ + patches/ds-bot/ (pin skipped: no git in this sandbox)

$ TZ=UTC node --test-concurrency=2 --import ./test/harness-resolve.mjs --test "test/*.test.js"
# tests 2180  # pass 2178  # fail 2   (both fail identically at base e4773eaa: check-arch-docs needs git; usage.sqlite fixture)

Review notes (tip c1fb9ac6d40f5c8cff333a313c2a30825e090a1c, base e4773eaae8903b58ebe327df8bae040b822252b3, tier T3 — core/src/host/authz.js is a T3 path):

• Scope. Content diff of the tip tree against the base tree is exactly the six files the body names (5 modified, 1 added: changelog.d/1788-social-read-owner.fixed.md). Nothing else moved, and the patch series carries no generated drift.
• The refusal sits in the served path. core/src/host/authz.js:246-250 answers bot/forbidden for flybot/social/share-friends with a body.botId the actor does not own, ahead of the flybotIsRead ALLOW. That endpoint is exactly what plugins/social/src/social.js:3233 registers with { read: true } (({ botId }) => shareFriendsForBot(botId)), the body reaches rt.authorize(actor, endpoint, body) at core/src/host/channel.js:297, and botOwnedBy (authz.js:89) compares ownerId to actor.memberId — so the cross-member read and the identity/grant sync behind it are both closed.
• Nothing else narrowed. SHARED_BLOCKED, tokens and the read set are untouched; the no-actor path is unchanged (bot/unauthorized only where enforcement already applied), and the new test pins all four cases: foreign Bot refused, own Bot still ALLOW, legacy no-actor install ALLOW, enforcement-on no-actor bot/unauthorized.
• Red first. Reverting only the changed source to the base blob turns the new case red with the expected old behaviour ({"ok":true}), 20/21; the rest of the file is unaffected.
• Generated mirrors and docs. patches/ds-bot/files/src/host/authz.js and .../files/test/authz.test.js are byte-identical to their core/ sources; the patch chain applies and core/ equals ds-bot/ + patches; docs/subsystems/core-host.md records the narrowing and the Docs-not-needed question does not arise.
• CI at this tip. tests-ok, merge-gate, judge, package, plugins (tree|social|timeline|workflow) and Node 24 · DSH are green. enqueue-guard is red for one reason only — no Verifier report names the tip c1fb9ac6d40f — which this PASS answers; the fork exemption means the missing agent-pr label and the header lines are not asked of this pull request.
• Not run here: the plugin suites and npm run verify (no git/node_modules in this sandbox); CI covers them at this tip.