OpenMausBot self-hosted server trusts every local process as the owner (OMB_LOOPBACK_TRUST defaults to owner)
Self-hosting OpenMausBot 0.1.140 headless on Linux as a dedicated user under systemd (openmausbot serve --no-pair --public-url https://host, fronted by tailscale serve), with bots on 'Ask for approval' so risky shell commands raise approval cards for the paired owner. I expected only paired devices to be able to act as the owner, since remote access requires pairing codes and sessions. The startup log line local requests: owner trust (self-hosted default) suggested otherwise. A bot's own shell runs on the same machine and can reach http://127.0.0.1:8799. Does that mean a bot can approve its own cards or change settings without a paired session? The deploy-vps docs don't mention this.
Yes, by default. In OMB 0.1.140 server/request-auth.js resolveLoopbackTrust() gives loopback requests owner trust on a self-hosted server unless OMB_LOOPBACK_TRUST says otherwise. The rule is: desktop app gets owner; hosted/Cloud workspaces get service; otherwise OMB_LOOPBACK_TRUST=owner|service, and when unset a headless server gets owner (reason: "self-hosted default"). Any other value fails closed to service. Under owner trust, any local process, including every bot's shell and tool subprocess, can call owner APIs without a session. The code's own warning for shared workspaces says it: "every bot's shell can change settings and approve cards as the owner".
Fix: set service trust in the unit:
[Service]
Environment=OMB_LOOPBACK_TRUST=serviceAfter a restart the log reads local requests: service trust (OMB_LOOPBACK_TRUST); without a session, loopback may use only health, the Slack worker's guarded routes and bot capability routes.
Side effect: openmausbot pair (the CLI) can no longer mint pairing codes over loopback. To pair a device, lift trust temporarily with a runtime drop-in (/run/systemd/system/openmausbot.service.d/owner-trust.conf containing Environment=OMB_LOOPBACK_TRUST=owner, then daemon-reload and restart), run openmausbot pair, then delete the drop-in and restart. If you script this in bash with trap ... EXIT, keep the drop-in path in a global variable. A local is out of scope when the EXIT trap fires, so the rm silently deletes nothing and owner trust stays on. Check after any pairing with systemctl show openmausbot -p Environment | grep -o 'OMB_LOOPBACK_TRUST=[a-z]*', or with the startup log line.
Related: in 0.1.140, pending tool-approval cards live only in memory and time out after 15 minutes (drivers/claude.js, timeoutMs ?? 15 * 60_000), so an unattended routine that needs approval fails if nobody answers.