The Dockerfile for the build of the Jenkins Docker Image specifies a user. How does this work?

Question

There are a few Dockerfile in the Git repository for Jenkins Docker Images.

I found this one, which I think is a suitable example to look at:

• https://github.com/jenkinsci/docker/blob/master/debian/bookworm/hotspot/Dockerfile

In this file, the user is specified to have name jenkins and uid 1000.

Initially, I tried to create the following docker-compose.yaml file to run an instance of Jenkins.

# docker-compose.yaml
services:
    jenkins:
        image: jenkins/jenkins:lts
        container_name: jenkins_lts
        ports:
            - 8090:8080
            - 50000:50000
        volumes:
            - /home/user/jenkins_compose/jenkins_configuration:/var/jenkins_home
            - /var/run/docker.sock:/var/run/docker.sock
networks:
    jenkins_network:
        name: jenkins-network-1
        driver: bridge

When I tried to start the container using docker compose up -d, I got errors relating to the Jenkins process inside the container being unable to obtain Read/Write access to /var/jenkins_home.

This volume is mounted using the path /home/user/jenkins_compose/jenkins_configuration on the host.

The user and group names are irrelevant, however the user id (UID) and group id (GID) are important.

This directory currently has UID and GID set to 1002:1002. That is the username and group for my WSL user.

What I don't understand is why the Dockerfile used to build this Jenkins Docker Image (assuming I am looking at the right file) specifies the user 1000.

On this system, the user id 1000 belongs to a user called ubuntu.

$ id -nu 1000
ubuntu

That seems to be the default username for a different version of WSL in other words, it was for a WSL Ubuntu 22.04, not the current one I am using which is 24.04.

In short: My question is this. Why specify a user id of 1000 when the Docker Image has no idea which user this will be when it runs, or even if this user id will exist. This is only known when the Docker Container runs.

Answer 1

In short: My question is this. Why specify a user id of 1000 when the Docker Image has no idea which user this will be when it runs, or even if this user id will exist. This is only known when the Docker Container runs.

Because it has to. On Linux, a process has to belong to a user and a user has to exist in /etc/passwd. Well, in theory it doesn't have to exist in /etc/passwd but it causes problems, for example:

$ docker run --rm -it -u 5000 golang
I have no name!@17f0cf278102:/go$ echo $HOME
/
I have no name!@17f0cf278102:/go$ ssh-keygen
No user exists for uid 5000

As you see we were able to start a container with an arbitrary user ID but HOME is set to / and some tools such as ssh-keygen will not work properly.

UID 1000 is an arbitrary choice to avoid running everything as root, or in general a user with UID 0 for security reasons, and it's very popular and the default UID on multiple Linux distributions.

In general, the disagreements between UIDs on host and inside containers is the source of multiple problems in Docker world. There are at least 2 problems I can think of off the top of my head.

The first problem is that since https://github.com/git/git/commit/8959555cee7ec045958f9b6dd62e541affb7e7d9 a user that has a different UID in the docker container, including UID 0 cannot do anything winth Git repositories. It's easy to reproduce:

$ git init
Initialized empty Git repository in /tmp/docker-test/.git/
$ date > FILE
$ git add FILE
$ git commit -m"initial commit"
[main (root-commit) 0d6d2a0] initial commit
 1 file changed, 1 insertion(+)
 create mode 100644 FILE
$ id
uid=1000(ja) gid=100(users) groups=100(users),16(dialout),17(audio),83(plugdev),86(netdev),215(vboxusers),281(docker)
$ docker run --rm -it -v "$PWD":/workspace -w /workspace golang
root@a6cb4fa37869:/workspace# id
uid=0(root) gid=0(root) groups=0(root)
root@a6cb4fa37869:/workspace# git status
fatal: detected dubious ownership in repository at '/workspace'
To add an exception for this directory, call:

    git config --global --add safe.directory /workspace

I read that some CI build systems, for example GitLab Runner tried to solve this problem by always add a safe directory automatically: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29022. I have never used GitLab Runner so I cannot say if it does it now but I know that neither Jenkins nor Bamboo did it last time I used them.

The second problem is cleaning up the directories created inside the Docker container during the CI run on the host. In *nix world generally one can remove a directory that belongs to a different user, even with UID 0 if one has a write and exec bit on the parent directory but the directories inside this directories cannot be removed. For example:

$ docker run --rm -it -v "$PWD":/workspace -w /workspace golang
root@008d2a0e079d:/workspace# id
uid=0(root) gid=0(root) groups=0(root)
root@008d2a0e079d:/workspace# mkdir one
root@008d2a0e079d:/workspace# mkdir -p two/three

On the host we now have this:

$ ls -ld one two
drwxr-xr-x 2 root root 4096 Nov 10 16:37 one
drwxr-xr-x 3 root root 4096 Nov 10 16:36 two

A user on the host with UID 1000 can remove one:

$ id
uid=1000(ja) gid=100(users) groups=100(users),16(dialout),17(audio),83(plugdev),86(netdev),215(vboxusers),281(docker)
$ rm -rf one
$ echo $?
0

But not two:

$ rm -rf two
rm: cannot remove 'two/three': Permission denied

Bamboo solves this problem by running its cleanup stage inside the docker container but on Jenkins and other CI systems the typical method of solving this problem involves running chmod 777 on everything in the build allowing users on host to remove it.