[SOLVED] How can I manipulate storage devices outside of Docker?

How can I manipulate storage devices outside of Docker?

I'd like to spin up an Ubuntu image with certain tools like testdisk for disk recovery. How can I manage all detected volumes on the host machine with testdisk inside a Docker container?

Solution

Yes. When you start a container with Docker’s --privileged flag, you are effectively giving it almost the same level of access to the kernel and device nodes as processes running directly on the host. In particular:

All capabilities are enabled. By default, Linux drops many of the “dangerous” capabilities (like CAP_SYS_ADMIN, CAP_MKNOD, etc.) inside a container. --privileged turns all of them back on.
Device cgroup restrictions are lifted. Normally a container sees only the device nodes you explicitly bind-mount (or that Docker automatically exposes). Under --privileged, the container’s view of /dev is unconfined—so it can see, open, and operate on block devices like /dev/sda, /dev/nvme0n1, etc.

Once a privileged container sees /dev/sda (or whatever your raw disk device is), it can use standard Unix tools—dd, parted, fdisk, mkfs, or even mknod—to overwrite partitions, reformat filesystems, corrupt the MBR/GPT, or otherwise destroy data. In short, you’ve just nullified Docker’s isolation for storage and given that container full license to modify any raw disk on the host .

Example

# This gives the container full access to all host devices…
docker run --rm -it --privileged \
  ubuntu:24.04 \
  bash

# Inside the container you could then do, e.g.:
#   dd if=/dev/zero of=/dev/sdb bs=1M count=100

Mitigations

If you need a container to work with specific devices but want to limit scope:

Don’t use --privileged.

Bind-mount only the exact devices you need with --device:

docker run --device=/dev/sdb:/dev/sdb:rw --cap-add=SYS_ADMIN your-image

Drop unneeded capabilities with --cap-drop (or only add the ones you really need via --cap-add).
Use user namespaces or rootless Docker, so that even if the container has root inside, it maps to an unprivileged UID on the host.

By carefully granting only the device nodes and capabilities you truly require, you can avoid exposing your host’s raw disks to arbitrary container code.