How do I set policies per domain?

Every setting that steers behaviour is a policy on three levels: global (the whole host), account (one CyberPanel user) and domain (one website or child domain). The more specific level wins, and each level may inherit or override individual keys. Inside a domain there can also be path rules using globs relative to the document root.

Reading and writing

shelltrap policy get global
shelltrap policy set global signature.action=report hash.action=report
shelltrap policy set domain 42 heuristics.action=quarantine
shelltrap policy effective site 42

policy effective is the one to use in an argument: every key comes back with its value and its origin — domain, account, global or default — so inheritance is visible rather than inferred. The plugin shows the same global → account → domain inheritance on the policy page.

The keys

  • upload.enabled — whether the synchronous upload gate is consulted (default on)
  • upload.on_erroropen or closed when the gate cannot answer (default open)
  • upload.timeout_ms — gate budget per request, capped at 60000 (default 2000)
  • upload.max_size — the largest upload the gate inspects
  • heuristics.actionreport, quarantine or off (default report)
  • heuristics.threshold — the score above which a heuristic hit counts
  • signature.action — action on a signature hit (default quarantine)
  • hash.action — action on a hash hit (default quarantine)
  • notify.targets — who is told, and how
  • scan.window — when scheduled scans may run
  • scan.exclude — path globs excluded from scheduled scans
  • realtime.enabled — whether the real-time watcher acts for this scope (default on)
  • quarantine.retention_days — default 30
  • findings.retention_days — default 180

How a file is assigned to a domain

The broker keeps a document-root index from the CyberPanel database (website, child domain, document root, owner), refreshed on a timer and on panel changes. File events are mapped to an account and a domain by the longest matching document-root prefix. The PHP adapter passes DOCUMENT_ROOT and SERVER_NAME; the document root decides and the server name is only a plausibility check. Files outside every document root — mail, backups, the home root — fall under the account policy.

What resellers and customers may change

upload.on_error and heuristics.action stay locked for resellers and customers at all times, and the broker enforces that independently of the user interface. An administrator can narrow the released keys further through the plugin's Django settings; if a role is missing from an explicit allowlist, or a setting is invalid, the plugin refuses the write fail-safe rather than guessing.

Policies are versioned

A policy change invalidates only the path-dependent policy verdicts of the affected domain, not content verdicts. Changing a policy therefore does not trigger a full rescan of the host.


Was this article helpful?

mood_bad Dislike 0
mood Like 0
visibility Views: 0