serve docker: document that socket access allows command execution

The volume plugin parses the remote option as a trusted connection
string, which can run local commands via backend options. Spell out
that access to the unix or TCP socket is equivalent to command
execution as the serving user, document the unix socket permissions,
and warn that the TCP socket is unauthenticated.
This commit is contained in:
Nick Craig-Wood
2026-06-25 16:30:44 +01:00
parent 9ab8e4724a
commit 1c681d05b2

View File

@@ -37,3 +37,27 @@ directory with book-keeping records of created and mounted volumes.
All mount and VFS options are submitted by the docker daemon via API, but
you can also provide defaults on the command line as well as set path to the
config file and cache directory or adjust logging verbosity.
## Security
The plugin API accepts a `remote` (aka `fs`) option on volume creation, and this
is parsed exactly like an rclone connection string. Connection strings are
trusted configuration: they may carry inline backend options, and some backends
use those options to run local commands (for example the `sftp` backend's `ssh`
option spawns an external binary). Anyone who can send requests to the plugin
socket can therefore make rclone run arbitrary commands as the user running
`rclone serve docker` (typically root). Treat access to the socket as equivalent
to that level of access and only expose it to trusted callers.
When listening on the default unix socket at `/run/docker/plugins/rclone.sock`
rclone creates it with mode `0660` owned by `root` and the group given by
`--socket-gid` (the process GID by default), so only root and members of that
group - normally just the docker daemon - can reach it. Do not loosen these
permissions or hand the group to untrusted users.
When using `--socket-addr` to listen on a TCP socket there is no authentication
and the API is reachable by anyone who can open the port, so bind it to a
loopback or otherwise trusted address and protect it with a firewall. Note that
holding Docker daemon access is already equivalent to root on the host, so a
caller able to issue `docker volume create` does not gain anything new from
this; the concern is exposing the socket more widely than the daemon itself.