provisioning.template.set / provisioning.common.set accept arbitrary unvalidated strings #34

New issue

Open

opened 2026-05-25 09:32:44 +00:00 by zaelgohary · 0 comments

zaelgohary commented

2026-05-25 09:32:44 +00:00

Member

Problem

Both provisioning.template.set and provisioning.common.set accept any string as a repo / service name without checking it against the available list (or any real source of truth). Bogus entries get persisted to /etc/hero/provisioning.toml silently and only blow up later when provisioning.template.apply / provisioning.common.apply runs.

Reproducer (against today's development tip)

SOCK=/root/hero/var/sockets/hero_codescalers_server/rpc.sock
curl --unix-socket $SOCK http://localhost/rpc -d '{"jsonrpc":"2.0","id":1,"method":"provisioning.template.set","params":{"repos":["hero_does_not_exist_anywhere"]}}'
# → ACCEPTED. template.current is now ["hero_does_not_exist_anywhere"].

Same behavior for provisioning.common.set with bogus service names:

curl --unix-socket $SOCK http://localhost/rpc -d '{"jsonrpc":"2.0","id":1,"method":"provisioning.common.set","params":{"services":["hero_doesnt_exist"]}}'
# → ACCEPTED. common.current is now ["hero_doesnt_exist"].

In both cases the daemon serialises the bogus list straight into /etc/hero/provisioning.toml. The error surfaces only when an operator runs the matching apply and the build / per-user init fails.

Suggested fix

In the provisioning.template.set and provisioning.common.set handlers, reject entries that aren't present in the matching available list with a clear Method param: unknown repo "x" style error before persisting. (Tolerate empty list since that already appears to be a no-op / reset semantics.)

Impact

Quiet config corruption. Operators see no error at set time and only discover it during the next apply / rollout. Not security-critical (root-only RPCs), but a usability footgun.

## Problem Both `provisioning.template.set` and `provisioning.common.set` accept any string as a repo / service name without checking it against the `available` list (or any real source of truth). Bogus entries get persisted to `/etc/hero/provisioning.toml` silently and only blow up later when `provisioning.template.apply` / `provisioning.common.apply` runs. ## Reproducer (against today's development tip) ```bash SOCK=/root/hero/var/sockets/hero_codescalers_server/rpc.sock curl --unix-socket $SOCK http://localhost/rpc -d '{"jsonrpc":"2.0","id":1,"method":"provisioning.template.set","params":{"repos":["hero_does_not_exist_anywhere"]}}' # → ACCEPTED. template.current is now ["hero_does_not_exist_anywhere"]. ``` Same behavior for `provisioning.common.set` with bogus service names: ```bash curl --unix-socket $SOCK http://localhost/rpc -d '{"jsonrpc":"2.0","id":1,"method":"provisioning.common.set","params":{"services":["hero_doesnt_exist"]}}' # → ACCEPTED. common.current is now ["hero_doesnt_exist"]. ``` In both cases the daemon serialises the bogus list straight into `/etc/hero/provisioning.toml`. The error surfaces only when an operator runs the matching `apply` and the build / per-user init fails. ## Suggested fix In the `provisioning.template.set` and `provisioning.common.set` handlers, reject entries that aren't present in the matching `available` list with a clear `Method param: unknown repo "x"` style error before persisting. (Tolerate **empty** list since that already appears to be a no-op / reset semantics.) ## Impact Quiet config corruption. Operators see no error at set time and only discover it during the next apply / rollout. Not security-critical (root-only RPCs), but a usability footgun.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

lhumina_code/hero_codescalers#34

No description provided.

Rows
Columns