In-depth understanding of uid and gid in docker containers

By default, processes in the container run with root user privileges, and this root user is the same user as the root user in the host machine. It sounds scary, because this means that once the process in the container has the right opportunity, it can control everything on the host machine! In this article, we will try to understand how usernames, group names, user ids (uids), and group ids (gids) are mapped between processes inside a container and the host system, which is very important for the security of the system. Note: The demonstration environment of this article is Ubuntu 16.04 (the picture below is from the Internet).

Let's first understand uid and gid

The Linux kernel manages uid and gid, and uses kernel-level system calls to decide whether a request should be granted privileges. For example, when a process attempts to write to a file, the kernel checks the uid and gid of the creating process to determine whether it has sufficient permissions to modify the file. Note that the kernel uses uid and gid, not username and group names.

For simplicity, the rest of this article only uses uid as an example. The system treats gid in basically the same way as uid.

Many students simply understand Docker containers as lightweight virtual machines. Although this simplifies the difficulty of understanding container technology, it can also easily lead to many misunderstandings. In fact, unlike virtual machine technology: all containers running on the same host share the same kernel (the host's kernel). The great value brought by containerization is that all these independent containers (actually processes) can share a kernel. This means that even if hundreds or thousands of containers are running on the Docker host, there is still only one set of uid and gid controlled by the kernel . So the same uid represents the same user in the host and the container (even if different usernames are displayed in different places).

Note that since the normal Linux tools for displaying usernames are not part of the kernel (such as commands like id), we may see the same uid displayed as different usernames in different containers. But you cannot have different privileges for the same uid, even in different containers.

If you already know the Linux user namespace technology, refer to "Linux Namespace: User". You need to note that so far, Docker does not enable user namesapce by default, which is also the case discussed in this article. The author will introduce how to configure Docker to enable user namespace in the next article.

The default user in the container is root.

If no relevant settings are made, the process in the container is started with root user privileges by default. The following demo uses the ubuntu image to run the sleep program:

$ docker run -d --name sleepme ubuntu sleep infinity

Note that sudo is not used in the above command. The author's login user in the host machine is nick, and the uid is 1000:

View the information of the sleep process in the host:

$ ps aux | grep sleep

The effective user name of the sleep process is root, which means that the sleep process has root privileges.

Then enter the container and see that the situation is the same as before. The sleep process also has root privileges:

So, is the root user in the container the same as the root user on the host?

The answer is: Yes, they correspond to the same UID. We have explained the reason before: the entire system shares the same kernel, and the kernel only manages one set of uid and gid.

In fact, we can simply verify the above conclusion through data volumes. Create a file on the host machine that only the root user can read and write:

Then mount it into the container:

$ docker run --rm -it -w=/testv -v $(pwd)/testv:/testv ubuntu

The file can be read and written in the container:

We can specify the user identity of the process in the container through the USER command in the Dockerfile or the --user parameter of the docker run command. Let’s explore these two situations separately.

Specifying user identity in Dockerfile

We can add a user appuser in the Dockerfile and use the USER command to specify that the program will be run as this user. The content of the Dockerfile is as follows:

FROM ubuntu
RUN useradd -r -u 1000 -g appuser
USER appuser
ENTRYPOINT ["sleep", "infinity"]

Compile into an image named test:

$ docker build -t test . 

Start a container using the test image:

$ docker run -d --name sleepme test

View the information of the sleep process in the host:

This time the effective user displayed is nick. This is because in the host machine, the name of the user with uid 1000 is nick. Then enter the container and take a look:

$ docker exec -it sleepme bash 

The current user in the container is the appuser we set. If you check the /etc/passwd file in the container, you will find that the uid of appuser is 1000, which is the same as the uid of user nick in the host machine.

Let's create another file that only user nick can read and write:

Also mount it into the container as a data volume:

$ docker run -d --name sleepme -w=/testv -v $(pwd)/testv:/testv test 

In the container, the owner of testfile becomes appuser, and of course appuser has the permission to read and write the file.

What exactly happened here? And what does this indicate?

First, there is a user nick with uid 1000 in the host system. Secondly, the program in the container runs as appuser, which is specified by us in the Dockerfile program through the USER appuser command.

In fact, there is only one uid 1000 managed by the system kernel. In the host machine, it is considered to be the user nick, and in the container, it is considered to be the user appuser.
So there is one thing we need to be clear about: inside the container, user appuser can obtain the rights and privileges of user nick outside the container. Privileges granted to user nick or uid 1000 on the host will also be granted to appuser inside the container.

Customize user identity from command line arguments

We can also specify the user identity of the process in the container through the --user parameter of the docker run command. For example, execute the following command:

$ docker run -d --user 1000 --name sleepme ubuntu sleep infinity

Because we specified the parameter --user 1000 on the command line, the effective user of the sleep process is displayed as nick. Enter the container and take a look:

$ docker exec -it sleepme bash 

What is going on? The user name is displayed as "I have no name!"! Check the /etc/passwd file, and there is indeed no user with uid 1000. Even without a user name, it does not affect the permissions of the user identity at all. It can still read and write files that only nick users can read and write, and the user information is replaced by uid instead of username:

It should be noted that the user identity specified by docker run --user when creating the container will overwrite the value specified in the Dockerfile.
We run two containers again using the test image:

$ docker run -d test

View the sleep process information:

$ docker run --user 0 -d test

Check the sleep process information again:

The process that specifies the --urser 0 parameter shows that the effective user is root, indicating that the command line parameter --user 0 overrides the setting of the USER command in the Dockerfile.

Summarize

From the examples in this article, we can see that the process running in the container also has the permission to access the host resources (Docker does not isolate users by default). Of course, in general, container technology will block the visible resources of the process in the container in the container. However, as we have demonstrated in the operations on files in the data volume, we can see that once the process in the container has the opportunity to access the resources of the host machine, its permissions are the same as those of the user on the host machine. Therefore, a safer approach is to specify a user with appropriate permissions for the process in the container instead of using the default root user. Of course, there is a better solution, which is to use Linux's user namespace technology to isolate users. In the following article, I will introduce how to configure Docker to enable user namespace support.

refer to:

Understanding how uid and gid work in Docker containers
Introduction to User Namespaces in Docker Engine
Isolate containers with a user namespace

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.