Understanding UID and GID in Docker containers

Docker container command 
By default, the process in the container runs with the root user, and the root user is the same user as root in the host. Sounds scary, because it means that once the process in the container has the right opportunity, it can control everything on the host! In this article we will try to understand how the user name, group name, User ID (UID), and group ID (GID) are mapped between processes and host systems within the container, which is important for the security of the system. Description: The demo environment for this article is Ubuntu 16.04 (from the Internet).


first to understand the next UID and GID

Docker command to start container
The UID and GID are managed by the Linux kernel, and the kernel-level system calls determine 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 creation process to determine if it has sufficient permissions to modify the file. Note that the kernel uses UID and GID instead of user name and group name .
For simplicity, the remainder of this article only takes the UID for example, docker command for running containers ,the system treats GID in the same way as the UID.


Docker commands to run a container


Many students simply understand the Docker container as a lightweight virtual machine, although this simplifies the difficulty of understanding container technology but it also leads to a lot of 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 of being containerized is that all these separate containers (in fact, processes) can share a single kernel. This means that even though hundreds or thousands of containers are running on the Docker host, the kernel-controlled UID and GID still have only one set . So the same UID represents the same user in the host and container (even if different user names are displayed in different places).
Note that because the normal Linux tools used to display the user name are not part of the kernel (such as the ID command), we may see the same UID appearing as a different user name in different containers. However, you cannot have different privileges for the same UID, even in different containers.


Docker command from container


If you already know the Linux User namespace technology, refer to "Linux Namespace:user", you should note that so far, Docker by default does not enable user Namesapce, this is the case discussed in this article. I'll show you how to configure Docker to enable user namespace in the next article.

Docker container bash command

The root user is used by default in the container


If you do not make the relevant settings, the process in the container starts with the root user right, and the following demo runs the sleep program using the Ubuntu Image:



$ docker run-d sleep Infinity



Note that sudo is not used in the above command. The author of the host in the login user is nick,uid for 1000:










To view information about the sleep process in the host:



PS grep Sleep








The valid user name for the sleep process is root, which means that the sleep process has root privileges.
Then go inside the container and see the same situation as before, and 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. The reason we explained earlier is that the entire system shares the same kernel, and the kernel only manages a set of UID and GID.





In fact, we can use the data volume to simply verify the above conclusions. Create a file on the host that only the root user can read and write to:










Then mount it in 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 via the user command in Dockerfile or the--user parameter of the Docker Run command. Let's explore both of these situations separately.



specifying user identities in Dockerfile


We can add a user appuser in Dockerfile and use the user command to specify that the program be run as that person, Dockerfile the following:



 -g appuseruser appuserentrypoint ["sleep""Infinity "]



Compile the image known as test:



$ docker build-t test.








Start a container with the test image:



$ docker run-d--name SLEEPME test



To view information about the sleep process in the host:










The valid user for this show is Nick, because in the host, the name of the user with UID 1000 is nick. Then go into the container and look at:



$ docker exec-it SLEEPME Bash








The current user in the container is the appuser we set up, if you look at the/etc/passwd file in the container, you will find that the Appuser uid is 1000, which is the same as the UID of the user nick in the host.





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










It is also mounted as a data volume in a container:



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








The owner of the testfile in the container actually becomes appuser, and of course Appuser has permission to read and write the file.





What the hell is going on here? And what does that mean?
First, there is a user with a UID of 1000 in the host system, Nick. Second, the program in the container is run as Appuser, which is specified by us through the USER appuser command in the Dockerfile program.
In fact, the system kernel management UID 1000 only one, in the host it is considered user nick, and in the container, it is considered to be user appuser.
So one thing we need to be clear: Inside the container, user Appuser is able to get the rights and privileges of Nick, the external user of the container. Granting the user Nick or UID 1000 privileges on a host will also grant appuser within the container.



Customizing user identities 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:



 + Sleep Infinity








Because we've instructed the parameter--user 1000 on the command line, the effective user of the sleep process here is shown as Nick. Go inside the container and look at:



$ docker exec-it SLEEPME Bash








What's the situation? The user name actually appears as "I have no name!"! To see the/etc/passwd file, there is no user with UID 1000. Even if there is no user name, it does not affect the user's identity, it can still read and write to only Nick users to read and write files, and user information is replaced by the UID user name:










It is important to note that the user identity specified through Docker run--user when the container is created overrides the value specified in Dockerfile.
We rerun the test image to run two containers:



$ docker run-d Test



To view the sleep process information:








0 -D test



Review the Sleep process information again:










The process that specified the--urser 0 parameter shows that the valid user is root, stating that the command line parameter--user 0 overrides the settings of the user command in Dockerfile.



Summary


From the examples in this article we can see that the processes running in the container also have access to the host resources (Docker does not isolate the user by default), and of course container technology blocks the visible resources of the processes in the container. However, we demonstrate that the operation of the files in the data volume shows that once the process in the container has the opportunity to access the resources of the host, its permissions are the same as the permissions of the user on the host. It is therefore safer to specify a user with the appropriate permissions for the process in the container rather than the default root user. Of course there is a better solution, which is to isolate users using Linux's user namespace technology, and I'll show you how to configure Docker to turn on user namespace support in the next article.





Reference:
Understanding how UID and GID work in Docker containers
Introduction to User namespaces in Docker Engine
Isolate containers with a user namespace