Action classes & denylist
The four action classes, their limits, and the commands nothing can run.
Reference for the action system. The guarantees behind these rules are explained in the safety model.
Classes
| Class | What it does | Built-in limits |
|---|---|---|
config_edit | Applies a fix to a plugin config as a diff | Timestamped backup first; all-or-nothing apply; one-click rollback. Paths must be relative, inside the server root, and match an allowlisted glob. Can never target server.properties, ops.json or banned-ips.json |
console_command | Runs a console command | Only commands on the allowlist you define, and never anything on the denylist below |
plugin_toggle | Enables or disables a plugin | Can never disable the MCTotem agent itself |
restart_request | Requests a server restart | A request only; it never issues a console stop |
Each class is enabled separately per server and starts disabled, in approve-each mode.
The hardcoded command denylist
These commands are refused no matter what, and the denylist overrides any allowlist. It is enforced in the MCTotem backend and, independently, inside the agent plugin on your server:
op, deop, stop, restart, ban-ip, pardon-ip, reload, executeIn addition, any command or path containing one of these substrings is refused, blocking secret access, privilege escalation and path traversal:
server.properties, rcon, ops.json, sudo, .., ` (backtick), $(Validation before anything runs
Proposed actions are schema-validated individually; malformed ones are dropped before they are even stored. The allowlist and denylist run at proposal time, at approval time, and at execution time on your server, each check independent of the others.
Related
Last updated on