docker mount user rights issue volume, understanding uid docker container
directory
problems encountered
reasons
vessel sharing host of uid
If you do not specify a user, the inner vessel default root user to run the
same container internal users and external users permission
must ensure that the container executive authority data corresponding to the volume and mount
a more pronounced demo
reference
docker volume mount user authority, uid container appreciated docker
In the beginning the use of docker volume mount data volume, the problem often do not have permission.
Here the user uid to understand the docker container to use, understand and map relationships inside and outside the container uid through the problems encountered.
Problems encountered
local node of a project needs to be compiled using docker to run npm install.
sudo docker run -it --rm --name ryan \
-v pwd:pwd \
-w pwd node
npm install --registry=https://registry.npm.taobao.org
It can be seen after the install, the permissions node_modules file into the root. Then, as users we do not have permission to delete this file.
Why file permissions docker output would be root?
The reason
time is running Docker container, if not specifically designated user, the default run as root. Dockerfile mirrored in our node is not specified user.
Container of execution of the user id is 0, 0 is the output file permissions.
以下参考Understanding how uid and gid work in Docker containers
Uid container share the host's
first understand the uid, gid implementation. The Linux kernel is responsible for managing uid and gid, and is determined by the kernel level system call if requested by the authority.
For example, when a process tries to write a file, the kernel will check the process of creation of the user's uid and gid, to determine if the process has permission to modify this file.
There is no use of username, but uid.
When the docker container when running on the host, and is still only a kernel. Container shared host kernel, all uid and gid are controlled by the same core.
Why I containers username and host kernel is not necessarily the same? For example, the user is called superset superset container, and the machine does the user superset. This is because the username is not part of the Linux kernel. Simply put, username is a mapping of uid.
However, according to the access control is uid, and not username.
That’s because the username (and group names) that show up in common linux tools aren’t part of the kernel, but are managed by external tools (/etc/passwd, LDAP, Kerberos, etc). So, you might see different usernames, but you can’t have different privileges for the same uid/gid, even inside different containers
If you do not specify a user, the interior of the container using the root user to run by default
we continue to use a mirror node, you can view Dockerfile at github. Which created a
uid for the user node 1000, but did not specify run user.
docker run -d --rm --name ryan node sleep infinity
user I perform for ryan (uid = 1000), so that the background vessel sleep program.
We can see, the execution of user processes sleep outer container is root. Interior of the container the user is 0 (root). While the user is performing docker run ryan.
In other words, I was able to go to an ordinary user to execute a command as root. It looks very scary look.
The same rights as the external users of the container internal user
permission is judged by uid. The next test, the user can modify the same uid attributable to the uid of the file.
There are a host user ryan:
Just node mirrored used Dockerfile also defines the user node 1000's:
We wrote a document in a local, home subscriber ryan
Then, by way of volume loading, as the user specifies operation 1000, start the container node:
docker run -d --rm --name test -u 1000:1000 -v $(pwd):/tmp node sleep infinity
It can be seen perform sleep outside the container process, user is ryan (another instance of sleep is carried out in front of the root user, and not deleted).
That is, docker run -u user can specify the host running docker command, the process -u uid is specified docker actual operation of the owner.
Then go inside the container, see if you can modify mounted file.
You can see, we have a show mounted file owner is the node, that is, uid = 1000 users inside the container. And have permission to view and modify.
Then, we write a file b, inside the container, this b naturally belong uid = node 1000's. Take a look outside the container:
Similarly, the outer container belonging uid = b show user ryan 1000, and have permission to view and modify.
So, it can prove both inside and outside of the container and the corresponding share uid permission.
We must ensure that rights of performers and mount the container volume data corresponding to
the initial question of this paper is as container rights performer and mount different data volumes. Running inside the container is uid = 0 users, data volume dependent and the uid = ryan 1000. Eventually leading container file permissions to write data volumes upgraded to root, so that ordinary users can not access.
If you mount the root file into the container, and the container internal execution uid is not 0, the error does not have permission. Mount npm cache when I encountered this problem, so with this article.
A more obvious demo
above demo is just the host machine and the container there is a uid = 1000 users, so very harmonious achieve a shared file permissions. Next, a more significant test demo.
Host machines and containers are not uid = 1111, 1111 to execute our containers:
docker run -d --rm --name demo -u 1111:1111 -v $(pwd):/tmp node sleep infinity
Current data volume has a file and dir any_user. A file ownership and uid = 1000, dir any_user anyone can write
to run container, and with uid = 1111 execution
inside the container log on, view the data volume and found a file and dir any_user vested uid = 1000 in Node (uid mapping)
since the inner container is not user uid = 1111, the display I have no name !, no username, no home.
Perform data volume inside the container writes, suggesting no authority. (Because the volume of the rights data is uid = 1000)
to write to a file in the common data area inside the container (777).
Next, look at the performance of the outer container:
Indeed the data file is written, read the contents of
the file permissions are written to the container 1111 uid. As the host does not have this user, uid displayed directly
view the process, the process can be found in the container is 1111
that is -u user specifies the execution inside the container, and the container external host user process, the same container written permission by the data volume is also this is specified.
Thus, the demo easier to understand the correspondence relationship of the inner and outer containers uid. After we understand when to mount data volume will not appear permissions problem.
Due to security issues, usually it does not recommend the use of root to run the container.
Reference
Understanding how uid and gid work in Docker containers
appreciated docker container uid and gid
Author: @Ryan Miao
This link: https://www.cnblogs.com/woshimrf/p/understand-docker-uid.html