document ops-user pi install and sudoers escalation policy
Adds the sysadmin setup recipe to the pi notes: run pi as a dedicated `ops` user with a tightly controlled sudoers allowlist instead of root, so an agent can do host work without unbounded privilege. Includes the AGENTS.md to drop at /home/ops/AGENTS.md. It records that the allowlist is discovered with `sudo -l` (hostnamectl, reboot, the dnf and systemctl subcommands, firewall-cmd, the ansible shim, libvirt/virsh and composer-cli, getfacl/setfacl, osbuild-auto.sh, btrfs scrub) and sets the hard rule for agents: when a command is not on that list, stop, do not attempt escalation workarounds, and ask the human to add the exact full-path sudoers line for review before proceeding. LLM-Generated: true
This commit is contained in:
@@ -68,3 +68,45 @@ This is my ~/.pi/agent/models.json
|
|||||||
}
|
}
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
|
## Installing for sysadmin work
|
||||||
|
|
||||||
|
I would absolutely recommend installing pi under a special user (I call mine
|
||||||
|
`ops`) with limited sudoers access that you tightly control. Pair that with the
|
||||||
|
following AGENTS.md at `/home/ops/AGENTS.md`:
|
||||||
|
|
||||||
|
```text
|
||||||
|
# AGENTS.md
|
||||||
|
|
||||||
|
## Sudo policy
|
||||||
|
|
||||||
|
The `ops` user on this machine has **limited sudoers capabilities**. The exact
|
||||||
|
allowlist is discoverable at any time with:
|
||||||
|
|
||||||
|
sudo -l
|
||||||
|
|
||||||
|
Allowed (NOPASSWD) commands currently include: `hostnamectl hostname`, `reboot`,
|
||||||
|
`dnf update/upgrade/install/remove/clean/makecache/autoremove`,
|
||||||
|
`dnf config-manager addrepo`, `systemctl start/restart/reload/enable`,
|
||||||
|
`firewall-cmd`, the ansible shim, `qemu-img`, `virsh`, `virt-install`,
|
||||||
|
`composer-cli`, `getfacl`, specific `setfacl` invocations,
|
||||||
|
`/usr/local/sbin/osbuild-auto.sh`, and `btrfs scrub`.
|
||||||
|
|
||||||
|
## Rule for agents
|
||||||
|
|
||||||
|
If you (the agent) believe you need a permission that is **not** in the
|
||||||
|
`sudo -l` allowlist — i.e., a command fails with a sudo permission error, or a
|
||||||
|
task requires root access you do not have — you must:
|
||||||
|
|
||||||
|
1. **Stop** and do not attempt workarounds that bypass sudo (no password
|
||||||
|
guessing, no escalating via other users, no trying to write to root-owned
|
||||||
|
paths without permission).
|
||||||
|
2. **Ask the human** to update sudoers with the specific command(s) you need,
|
||||||
|
stating exactly which command(s) and arguments should be added so the user
|
||||||
|
can review and approve them. Requests must be correct and copy-pastable,
|
||||||
|
using full command paths in standard sudoers format, e.g.
|
||||||
|
`ops ALL=(root) NOPASSWD: /usr/sbin/btrfs scrub*`
|
||||||
|
|
||||||
|
Do not proceed with root-only operations until the user has confirmed the
|
||||||
|
sudoers entries have been added.
|
||||||
|
```
|
||||||
Reference in New Issue
Block a user