Description
Split out of #32 as promised there, so a monitoring feature is not carrying a security decision along with it.
The Proxmox proposal included a third phase: provisioning guests through the Proxmox VE Community Scripts catalog. It is a genuinely useful idea and it is also unlike anything homebutler does today, which is why it needs its own discussion rather than a line in a Phase 1 PR.
Why it is different from install
homebutler install looks superficially similar — pick a name, get a running thing — but the trust model is not comparable.
Today install renders a compose template that lives in this repository (internal/install/install.go), hands it to Docker, and whatever runs stays inside a container. The catalog is curated in-tree, so what executes is whatever was reviewed when the entry was merged.
Phase 3 would fetch a shell script from an external catalog at runtime and execute it as root on the hypervisor. Three things change at once: the code is not reviewed by us, it is fetched at run time rather than pinned at build time, and it runs as root outside any container. It would also give homebutler its first code path that executes arbitrary shell — something deliberately avoided in #19, where docker exec was rejected on the same grounds.
What needs deciding
- Whether homebutler runs externally-authored code at all, or stops at generating and showing the command for a human to run
- If it does: pinning. A catalog reference by commit or checksum, verified before execution, versus fetching whatever is at a URL today
- What the MCP story is.
riskDestructive is the obvious classification, but an agent invoking root-level provisioning deserves more than a label — that likely needs the permission model that does not exist yet
- Whether the answer differs for a script the user names explicitly versus one homebutler selects from a catalog
Notes
No decision implied by opening this. It is here so #32 can land Phase 1 and 2 without settling it, and so the question is on the record rather than in a comment thread.
Raised by @gsaraiva2109 in #32.
Description
Split out of #32 as promised there, so a monitoring feature is not carrying a security decision along with it.
The Proxmox proposal included a third phase: provisioning guests through the Proxmox VE Community Scripts catalog. It is a genuinely useful idea and it is also unlike anything homebutler does today, which is why it needs its own discussion rather than a line in a Phase 1 PR.
Why it is different from
installhomebutler installlooks superficially similar — pick a name, get a running thing — but the trust model is not comparable.Today
installrenders a compose template that lives in this repository (internal/install/install.go), hands it to Docker, and whatever runs stays inside a container. The catalog is curated in-tree, so what executes is whatever was reviewed when the entry was merged.Phase 3 would fetch a shell script from an external catalog at runtime and execute it as root on the hypervisor. Three things change at once: the code is not reviewed by us, it is fetched at run time rather than pinned at build time, and it runs as root outside any container. It would also give homebutler its first code path that executes arbitrary shell — something deliberately avoided in #19, where
docker execwas rejected on the same grounds.What needs deciding
riskDestructiveis the obvious classification, but an agent invoking root-level provisioning deserves more than a label — that likely needs the permission model that does not exist yetNotes
No decision implied by opening this. It is here so #32 can land Phase 1 and 2 without settling it, and so the question is on the record rather than in a comment thread.
Raised by @gsaraiva2109 in #32.