[raesene9]

A couple of things :-

You can still mount filesystems as root from a container, if you have Docker command rights. In Docker's security model access to run docker commands on a given host == root, that's a design choice AFAIK, not an oversight.

It's perfectly possible to mitigate that issue, by restricting who can run containers and also ensuring that all containers specify and use a non-root user account (or enable user namespaces at the Docker daemon level)

Also, many early stage technologies don't prioritise security . For example, for several early releases of Kubernetes all you needed was remote access to a single port (10250/TCP) and you could get root access to the underlying host without any authentication...

[derriz]

If you run in your container as a non-root user, it makes working with volumes a pain. Who knows what the container user UID will map to on the host and whether this host user, if any, will have permissions to access files in the volume.

Otherwise you can hard code a UID when creating the user in the Dockerfile but that means your containers aren't generally portable.

In the end, the path of least resistance is to run as root within the container and simply accept the security implications if using volumes.

[budhajeewa]

In the Dockerfile, get UID and GID as ARGs, and make sure those variables are available in your host environment. Then when creating the user in Dockerfile, use that UID and GID. Volumes will work like a charm.

That's what I am doing for local development setups with Docker.

See https://github.com/a2way-com/template-docker-laravel/blob/ma... and its README.

[hbogert]

That means your docker file is portable, but your images are not, which is what your parent is referring to. It's a friggin mess. It's still the same as when I started using docker.