SECURITY: scope conversation reads to the authenticated user (Rust) — th-b2c60b

[brentrager]

SECURITY — cross-user data leak

list_conversations was scoped by org but not by user, and the resume path in create_conversation_session plus get_conversation_messages were not owner-checked at all. Any authenticated user in an org could enumerate and open every other user's conversations in that org. Reported by a downstream customer; being closed across all five language lanes.

Pearl: th-b2c60b (epic th-8fe998). This is the Rust lane.

The fix

Conversation reads carry a per-user scope derived only from the connection's verified principal (Principal::email, from the JWT email claim), on top of the existing org scope — defense in depth, not a replacement.

• list_conversations filters in the storage query via the new StorageAdapter::list_conversations_by_org_and_user. Postgres pushes it into one EXISTS query; the trait's default implementation filters conversations through their participants, so DynamoDB, in-memory, and any downstream adapter are scoped by construction rather than fail-open. Filtering in the query (not after the limit) keeps a page from silently coming back short.
• Resume + get_conversation_messages are owner-checked.
• create_conversation_session stamps the principal's email on the session's user participant. The client-supplied userEmail no longer decides identity for an authenticated connection — that was the spoofing vector. Same fix applied to the Lambda transport's create path, which writes to the same store.

Fail-closed rules

connection	conversation reads
auth enabled, principal has an email	scoped to that email
auth enabled, no principal / no email claim	empty list, every read denied — never falls back to the org
auth disabled (none, unconfigured, or single-user local-token)	unscoped, unchanged — the smooth-daemon / LocalServer embedding is unaffected

An unknown auth mode is treated as multi-user, so a future verifier fails closed rather than silently unscoped.

No existence oracle

Reading another user's session returns the byte-identical SESSION_NOT_FOUND an id that never existed returns, and resuming another user's conversation mints a fresh conversation exactly as an unknown id already did. A distinct forbidden/denied response would confirm which ids are real — all enumeration needs.

Tests

Written from the attacker's side, two users in the same org. Verified load-bearing: 6 of them fail against the unpatched handler.

• A's list returns only A's conversations (+ case-insensitive email match)
• A resuming B's conversation, and A calling get_conversation_messages on B's session, are asserted identical to the never-existed payloads (not just the same variant)
• a create frame claiming someone else's email does not get that user's scope — the principal wins
• auth enabled + emailless principal ⇒ empty/denied, not unscoped
• auth disabled ⇒ unscoped parity preserved
• adapter conformance suites (in-memory, Postgres, DynamoDB) cover the new scoped query

cargo test --workspace 591 passed / 3 ignored · cargo clippy --all-targets no new warnings (8 pre-existing, pearl th-da8207) · cargo fmt --check clean for every touched file.

Docs: docs/Operations/Access Control.md gains the email claim and a "conversations are scoped per user, not just per org" section.

🤖 Generated with Claude Code

https://claude.ai/code/session_01331RwggrhiP9UJVao9dr1F

[changeset-bot]

🦋 Changeset detected

Latest commit: d9f6c73

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@smooai/smooth-operator	Minor
@smooai/smooth-operator-web-chat-example	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR