Description
Linux bind propagation controls how new submounts become visible between a host and a container. shared and rshared allow propagation in both directions. slave and rslave receive mount changes from the host side without sending changes back. The r prefix extends the setting to nested mounts.
Unnecessary propagation can expose data or create operational dependencies. Blocking propagation is different from preventing reads and writes to files already shared.
Potential impact
- Newly mounted data can become visible to unintended containers.
- With bidirectional propagation and permission to change mounts, container changes can affect the host or other mounts.
Remediation
- Keep the default
rprivatewhen propagation is unnecessary, or choose a suitable nonshared setting. - Where propagation is required, review its direction, nested mounts and actual sharing peers, and minimize mount-changing privileges.
- Test that required data access still works after the change. Mount propagation requires a Linux host and is not supported by Docker Desktop.
Examples
Supply the actual image and host path referenced by ENVVAR. Propagation also depends on the host’s source-mount settings.
Before
version: "3.2"
services:
app:
image: notreal
volumes:
- type: bind
source: $ENVVAR/.whew/path/datapath
target: /data
bind:
propagation: rshared
rshared can propagate nested mount changes in both directions.
After
version: "3.2"
services:
app:
image: notreal
volumes:
- type: bind
source: $ENVVAR/.whew/path/datapath
target: /data
bind:
propagation: private
private blocks propagation for this mount. Consider the default rprivate to apply private propagation recursively to nested mounts. File-access permissions still need separate restrictions.