I have a directory with permissions for user1:
$ ls -la owned-by-u1
drwxr-xr-x 19 u1 u1 4096 Sep 4 16:22 owned-by-u1
$ ls -nla
drwx------ 19 1001 1001 4096 Sep 4 16:22 owned-by-u1
when I map that directory as volume to a postgres container, it changes the owner of the directory to userid 999, which can map to different usernames.
$ ls -la owned-by-u1
drwx------ 19 gitlab-runner u1 4096 Sep 4 16:22 owned-by-u1
$ ls -nla
drwx------ 19 999 1001 4096 Sep 4 16:22 owned-by-u1
I run container like this
docker run -d
--name aaa-postgres
-e POSTGRES_PASSWORD=mysecretpassword
-e PGDATA=/var/lib/postgresql/pgdata
-v /home/u1/tt/owned-by-u1:/var/lib/postgresql/pgdata
postgres
Can somebody explain the mechanism please?
The dockerd is running as root (not rootless) and UID re-mapping is not enbaled.
If I enable uid re-mapping, the container crashes:
chmod: changing permissions of '/var/lib/postgresql/pgdata': Operation not permitted
find: ‘/var/lib/postgresql/pgdata’: Permission denied
chown: changing ownership of '/var/lib/postgresql/pgdata': Operation not permitted
Which is expected because the root inside is not a real root:
$ docker run
--name aaa-postgres
--entrypoint ""
-e POSTGRES_PASSWORD=mysecretpassword
-e PGDATA=/var/lib/postgresql/pgdata
-v /home/max/tt/owned-by-u1:/var/lib/postgresql/pgdata
postgres cat /proc/self/uid_map
gives this
0 296608 65536
which is in line with /etc/subuid:
$ cat /etc/subuid
dockremap:296608:65536
Here’s a bit of docker info:
$ docker context ls
NAME DESCRIPTION DOCKER ENDPOINT ERROR
default * Current DOCKER_HOST based configuration unix:///var/run/docker.sock
desktop-linux Docker Desktop npipe:////./pipe/dockerDesktopLinuxEngine
$ docker version
Client: Docker Engine - Community
Server: Docker Engine - Community
7
There’s no mapping of UID’s on volume mounts between the docker container and host. But usernames on both are controlled by the /etc/passwd and /etc/group file which is specific to the host and the container (so the username on the host will not match the username for the same uid inside the container).
With rootless mode and user namespaces, the containers can have their user and group id’s mapped (following /etc/subuid and /etc/subgid mappings and a specified user to the docker engine). When the containers uid and gid are shifted, that shifted uid and gid will appear in processes on the host and the user trying to access any bind mounts. In this scenario, root in the container is not root on the host, so filesystem operations that try to change ownership of a file on the host will fail the same as if you tried to run them as a random high numbered user outside of a container. If the file on the host is owned by a uid and gid outside of the mapped ranges, I believe it shows up as nobody in the container and any attempt to modify the file will fail since the container user does not have access.
With the postgres example, it is configured to start as root, and modify file permissions as part of the entrypoint. You should avoid host/bind mounts, and instead use a named volume for this scenario. You can see the chown commands to the postgres user in /usr/local/bin/docker-entrypoint.sh, and the current user and postgres user inside the container with:
# id
uid=0(root) gid=0(root) groups=0(root)
# id postgres
uid=999(postgres) gid=999(postgres) groups=999(postgres),101(ssl-cert)
Note, with Docker Desktop, there’s a VM that the docker engine is running inside of, and that VM has a filesystem driver mounting the host filesystems into the VM in a way that automatically maps uid and gid to the host user when writing files to avoid permission issues.
6