6 ms·

That would all be nice, if volumes would not be the exact same thing, where only the in-filesystem location is being managed by the docker daemon and not by the

• fulafel 7y ago
  Not necessarily, since the storage volume scenario doesn't have to be on the same host machine as the data you want to share to the container, you could eg share over a registry. But even in the same host case: 1) The most common use case of host volume mounts is usually to share your workspace to the container. That usually means mounting things from your project directory, maybe in your "src" or home directories, with the container, by default letting it write there too. This scenario is bad from both workflow hygiene and security POV, and there are clear UX advantages in the mental model of just using a more clearly bounded way of sharing data unidirectionally and in a explicit, controlled way. Plus you won't be asking other users to blindly trust your container with their host side files. 2) In many contexts (eg the Mac and Windows Docker apps) "docker" means containers running in virtual machines isolated from the host. 3) In Linux-native production setups with containers, the storage driver is using separate file systems, which offer isolation from many kinds of file descriptor and shared UID namespace based attacks from crossing over to other mounted filesystems (like the host OS and home directories).