fix(chat): require per-channel sender allowlist for inbound commands - #1
Merged
Conversation
Chat-channel commands (/task, /folder, /approve, …) spawn and drive agents with the host's full privileges, but the dispatcher routed purely on the command verb — sender_id was logged and used for context yet never authorized. Any user who could message the bot could run arbitrary tasks (RCE) and /approve always disabled the human-in-the-loop. This is acute for an always-on server reachable via Telegram. Add a fail-closed authorization gate at the top of dispatch_command (covers Telegram, Lark, and WeChat in one place): only sender ids listed in the channel's config_json `allowed_senders` may drive the bot. An empty/unset list authorizes no one; a blocked sender is told their own id so the operator can add it. Surfaced in the add/edit channel dialogs as an "Allowed Sender IDs" field. - chat_channel/authz.rs: pure is_sender_allowed() + unit tests - command_dispatcher.rs: gate before any command, incl. follow-ups - i18n.rs: unauthorized reply (10 languages) - add/edit-chat-channel-dialog.tsx: allowlist management UI Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
`pnpm build` (strict tsc) flagged the `.map((s) => …)` callback as implicit `any`: in the edit dialog `config` comes from `JSON.parse` (any), so the `allowedSenders` state inferred `any`. Type the state as `string` and annotate the map parameter. eslint doesn't run the type-checker so it passed locally; validated now with `pnpm build` + `pnpm test` (1747 passing). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Chat-channel commands (
/task,/folder,/approve, …) spawn and drive agents with the host's full privileges, butdispatch_commandrouted purely on the command verb —sender_idwas logged and used for context yet never authorized. Anyone who could message the bot could run arbitrary tasks (RCE), and/approve alwaysdisabled the human-in-the-loop. This is acute for an always-on server reachable via Telegram.What
dispatch_command(covers Telegram, Lark, and WeChat in one place): only sender ids in the channel'sconfig_json.allowed_sendersmay drive the bot. Empty/unset list ⇒ nobody is authorized.chat_channel/authz.rs— pureis_sender_allowed()with unit tests (6, passing).i18n.rs— unauthorized reply in all 10 languages.Validation
cargo test --no-default-features --bin codeg-server --lib chat_channel::authz→ 6 passedcargo clippy --no-default-features --bin codeg-server --lib -- -D warnings→ cleaneslinton changed components → cleanFollow-up (separate)
Defense-in-depth: scope inbound Telegram
getUpdatesto the configured chat_id (backends/telegram.rs).