The Security Model

The Security Model

Read-only by default

The overview commands (/diag, /nas-status, /smart-status, /health-summary, /logs, /dsm-update-check, /docker-list, /compose-list, /compose-logs) do not change the state of the NAS. Mutating actions require an explicit argument — for example a project name for /compose-up or a target path for /manage-mounts mount.

Dedicated SSH key

The plugin uses its own Ed25519 key — for a single NAS ~/.ssh/synology-manager-plus_ed25519, for several a dedicated one per NAS (~/.ssh/synology-manager-plus_<slug>_ed25519). That keeps each NAS independently rotatable and revocable, and leaves your other keys untouched.

Host key & no blind trust

On the first connection (via the interactive ! ssh-copy-id) you review and accept the host key fingerprint (Trust on First Use). All automated connections afterwards run with BatchMode=yes and use the cached key — there is no silent acceptance of unknown keys.

Input validation & protection against injection

Host, port, user, NAS slug and project names are checked against strict patterns before every use. The plugin assembles SSH calls internally as an argument array (never by string concatenation), and the Docker path is hard-wired to /usr/local/bin/docker. This keeps paths and parameters cleanly separated.

Errors are surfaced

Instead of swallowing errors silently, the plugin captures the standard error output from the NAS and shows it. If, say, a discovery step during /first-run fails, the command deliberately aborts rather than writing a half-populated profile.