Consider the following trivial Dockerfile:
RUN adduser --disabled-password --gecos '' docker
RUN adduser --disabled-password --gecos '' bob
docker build -t test .
docker run --rm -it -v $(pwd):/home/bob/subdir test
-rw-rw-r-- 1 docker docker 120 Oct 22 03:47 Dockerfile
chown -R bob:bob /home/bob
-rw-rw-r-- 1 bob bob 120 Oct 22 03:47 Dockerfile
-rw-rw-r-- 1 1001 1001 120 Oct 21 20:47 Dockerfile
Is that correct? Can someone point me to documentation of this, I'm just conjecturing based on the above experiment.
Perhaps this is just because they both have the same numerical value on the kernel, and if I tested on a system where my home user was not id 1000 then permissions would get changed in every case?
Have a read of
info coreutils 'chown invocation', that might give you a better idea of how file permissions / ownership works.
Basically, though, each file on your machine has a set of bits tacked on to it that defines its permissions and ownership. When you
chown a file, you're just setting these bits.
chown a file to a particular user/group using the username or group name,
chown will look in
/etc/passwd for the username and
/etc/group for the group to attempt to map the name to an ID. If the username / group name doesn't exist in those files,
chown will fail.
root@dc3070f25a13:/test# touch test root@dc3070f25a13:/test# ll total 8 drwxr-xr-x 2 root root 4096 Oct 22 18:15 ./ drwxr-xr-x 22 root root 4096 Oct 22 18:15 ../ -rw-r--r-- 1 root root 0 Oct 22 18:15 test root@dc3070f25a13:/test# chown test:test test chown: invalid user: 'test:test'
However, you can
chown a file using IDs to whatever you want (within some upper positive integer bounds, of course), whether there is a user / group that exists with those IDs on your machine or not.
root@dc3070f25a13:/test# chown 5000:5000 test root@dc3070f25a13:/test# ll total 8 drwxr-xr-x 2 root root 4096 Oct 22 18:15 ./ drwxr-xr-x 22 root root 4096 Oct 22 18:15 ../ -rw-r--r-- 1 5000 5000 0 Oct 22 18:15 test
The UID and GID bits are set on the file itself, so when you mount those files inside your docker container, the file has the same owner / group UID as it does on the host, but is now mapped to
/etc/passwd in the container, which is probably going to be a different user unless it's owned by root (UID 0).
The real question is, of course, 'what do I do about this?' If bob is logged in as bob on the given host machine, he should be able to run the container as bob and not have file permissions altered under his host account. As it stands, he actually needs to run the container as user docker to avoid having his account altered.
It seems like, with your current set-up, you'll need to make sure your UIDs > usernames in
/etc/passwd on your host match up to your UIDs > usernames in your containers
/etc/passwd if you want to interact with your mounted user directory as the same user that's logged in on the host.
You can create a user with a specific user id with
useradd -u xxxx. Buuuut, that does seem like a messy solution...
You might have to come up with a solution that doesn't mount a host users home directory.