Reputation: 495
The best practices page mentions the below: (https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user)
Consider an explicit UID/GID
Users and groups in an image are assigned a non-deterministic UID/GID in that the “next” UID/GID is assigned regardless of image rebuilds. So, if it’s critical, you should assign an explicit UID/GID."
What is the significance of explicitly specifying the UID/GID? Under what scenario allowing the system to assign the UID/GID does not provide sufficient security?
Explicitly specifying these values seem to have the downside of a leading to a situation in which the explicitly specified value (UID/GID) is already in use.
Upvotes: 2
Views: 1452
Reputation: 158758
I think this is more significant for the case where someone might be dependent on the specific numeric uid, maybe to inject data into a container.
# this needs to be readable by the container process
# it runs as non-root user "www-data"
# we think its uid is 18
sudo chown -R 18 data
sudo docker run -v ./data:/data -p 8888:80 imagename
Now if, due to changes in the base image outside either the image author's or end user's control, adduser
makes the uid be something else, recipes like this will break (the host has no direct way to see the container's /etc/passwd
file to know what the actual uid will be).
To work around that you maybe need a recipe like this:
# may or may not work to get the uid
CONTAINER_UID=$(sudo docker run --rm imagename id -u)
sudo chown -R "$CONTAINER_UID" data
Upvotes: 2