Description of problem: "Two suffixes :z or :Z can be added to the volume mount. These suffixes tell Docker to relabel file objects on the shared volumes. The 'z' option tells Docker that the volume content will be shared between containers. Docker will label the content with a shared content label. Shared volumes labels allow all containers to read/write content. The 'Z' option tells Docker to label the content with a private unshared label. Private volumes can only be used by the current container." However this doesn't seem to be the case when using volumes-from on the container that made the label changes using :Z If the same volume is mounted into a different container then a data volume using volumes-from will be prohibited as expect. Version-Release number of selected component (if applicable): How reproducible: $ sudo docker run -it -v /tmp/vol1:/data:z -v /tmp/vol2:/data2:Z --name=data-volume fedora:latest bash [root@91ac66d5a323 /]# exit exit $ ls /tmp/vol1 $ ls /tmp/vol2 $ sudo docker run --volumes-from=data-volume -d fedora:latest touch /data/mynewdata1 72123a307bd16262eb7d50d9518bf6d451a26419b228a85928f274ca7cc33583 $ sudo docker run --volumes-from=data-volume -d fedora:latest touch /data2/mynewdata2 5bfc3f563997670422b7aea93996efbefce85f5653bd52ec47ae35b78ea67aad $ ls /tmp/vol1 mynewdata1 $ ls /tmp/vol2 mynewdata2 Outside the container on the host: $ ls -alZ /tmp/vol1 drwxrwxr-x. whenry whenry system_u:object_r:svirt_sandbox_file_t:s0 . drwxrwxrwt. root root system_u:object_r:tmp_t:s0 .. -rw-r--r--. root root system_u:object_r:svirt_sandbox_file_t:s0 mynewdata1 $ ls -alZ /tmp/vol2 drwxrwxr-x. whenry whenry system_u:object_r:svirt_sandbox_file_t:s0:c180,c686 . drwxrwxrwt. root root system_u:object_r:tmp_t:s0 .. -rw-r--r--. root root system_u:object_r:svirt_sandbox_file_t:s0:c180,c686 mynewdata2 Inside data-volume container: [root@91ac66d5a323 /]# ls -alZ /data drwxrwxr-x. 1000 1000 system_u:object_r:svirt_sandbox_file_t:s0 . drwxr-xr-x. root root system_u:object_r:svirt_sandbox_file_t:s0:c566,c803 .. -rw-r--r--. root root system_u:object_r:svirt_sandbox_file_t:s0 mynewdata1 [root@91ac66d5a323 /]# ls -alZ /data2 drwxrwxr-x. 1000 1000 system_u:object_r:svirt_sandbox_file_t:s0:c566,c803 . drwxr-xr-x. root root system_u:object_r:svirt_sandbox_file_t:s0:c566,c803 .. -rw-r--r--. root root system_u:object_r:svirt_sandbox_file_t:s0:c566,c803 mynewdata2 Inside a container using --volumens-from=data-volume [root@507ee11c7998 /]# ls -alZ /data drwxrwxr-x. 1000 1000 system_u:object_r:svirt_sandbox_file_t:s0 . drwxr-xr-x. root root system_u:object_r:svirt_sandbox_file_t:s0:c496,c935 .. -rw-r--r--. root root system_u:object_r:svirt_sandbox_file_t:s0 mynewdata1 [root@507ee11c7998 /]# ls -alZ /data2 drwxrwxr-x. 1000 1000 system_u:object_r:svirt_sandbox_file_t:s0:c496,c935 . drwxr-xr-x. root root system_u:object_r:svirt_sandbox_file_t:s0:c496,c935 .. -rw-r--r--. root root system_u:object_r:svirt_sandbox_file_t:s0:c496,c935 mynewdata2 docker inspect of data-volume container: }, "Volumes": { "/data": "/tmp/vol1", "/data2": "/tmp/vol2" }, "VolumesRW": { "/data": true, "/data2": true }, "VolumesRelabel": { "/data": "z", "/data2": "Z" } However it does seem to prohibit writing to the volume if the same volume is bind mounted into a different container. So running a different volume container using the same /tmp/vol1 and /tmpvol2 that have the changed labels and dropping :z and :Z: $ sudo docker run -it -v /tmp/vol1:/data -v /tmp/vol2:/data2 --name=noz-data-volume fedora:latest bash Now start another container : $ sudo docker run --volumes-from=noz-data-volume -it fedora:latest bash [sudo] password for whenry: [root@d09259c53715 /]# touch /data/anewerfile [root@d09259c53715 /]# touch /data2/anewerfile touch: cannot touch ‘/data2/anewerfile’: Permission denied Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
dwalsh: how in BLAZES do we have 3 labels on the same file? system_u:object_r:svirt_sandbox_file_t:s0:c180,c686 system_u:object_r:svirt_sandbox_file_t:s0:c566,c803 system_u:object_r:svirt_sandbox_file_t:s0:c496,c935 Is there some sort of crazy device mapper stuff going on here with --volumes-from ? my brain does not understand how this is possible...
This is working as I would expect on my current docker in git. # docker run -it -v /tmp/vol1:/data:z -v /tmp/vol2:/data2:Z --name=data-volume fedora:latest bash [root@f17ee270d3f6 /]# ps -eZ LABEL PID TTY TIME CMD system_u:system_r:svirt_lxc_net_t:s0:c401,c666 1 ? 00:00:00 bash system_u:system_r:svirt_lxc_net_t:s0:c401,c666 25 ? 00:00:00 ps exit # docker run --volumes-from=data-volume -it fedora:latest bash [root@f17ee270d3f6 /]# ls -lZd /data* drwxr-xr-x. root root system_u:object_r:svirt_sandbox_file_t:s0 /data drwxr-xr-x. root root system_u:object_r:svirt_sandbox_file_t:s0:c401,c666 /data2 [root@f17ee270d3f6 /]# id uid=0(root) gid=0(root) groups=0(root) [root@f17ee270d3f6 /]# ps -eZ LABEL PID TTY TIME CMD system_u:system_r:svirt_lxc_net_t:s0:c48,c369 1 ? 00:00:00 bash system_u:system_r:svirt_lxc_net_t:s0:c48,c369 25 ? 00:00:00 ps [root@f17ee270d3f6 /]# The original container that created the private content on /data2:Z so it is labeled with the c401,c666 label, and would not be readable within the second container.
eparis it is more about docker changing the labels. only one label per inode.
Hi Dan, I need to test this more. I'm not sure I'm seeing the desired behavior even on my updated docker. Are you able to touch files in both mounts in the container using volumes-from? Docker version 1.6.0, build 350a636/1.6.0
If I mount with a "Z" then only the container that created the content should be allowed to touch it, no other containers should be allowed. If you run ls -Z on the directory you should see it with a non s0 MCS Label. If you mount with "z" you should see it with s0 for the MCS Value. In both cases the type should be svirt_sandbox_file_t.
There is definitely a bug here. docker-1.7.0-2.git50ef691.fc23.x86_64 I'll give the reproducer and then my analysis. Create the container which will be the volumes from: $ mkdir /mnt/private /mnt/public $ docker run -ti -v /mnt/private:/mnt/private:Z -v /mnt/public:/mnt/public:z --name=mountsfromhere fedora /bin/bash # echo public > /mnt/public/mypublic # echo private > /mnt/private/myprivate # exit Consume that container $ docker run -ti --rm --volumes-from=mountsfromhere --name=consumemounts fedora /bin/bash # cat /mnt/public/mypublic public # cat /mnt/private/myprivate private # exit Notice that /mnt/private was supposed to be inaccessible, but in fact we were able to read /mnt/private/myprivate. This is definitely a bug (if you ask me) Now my analysis: the problem is that the :Z is getting applied when you run the second container! After I create the "--name=mountsfromhere" container but BEFORE I run the "--name=consumemounts" container if I look at ls (from the host) I see: $ ls -lZ /mnt system_u:object_r:svirt_sandbox_file_t:s0:c374,c495 private system_u:object_r:svirt_sandbox_file_t:s0 public After I run the "--name=consumemounts" container if I look at ls (from the host) I see: $ ls -lZ /mnt system_u:object_r:svirt_sandbox_file_t:s0:c275,c841 private system_u:object_r:svirt_sandbox_file_t:s0 public So running the second container, with the --volumes-from argument caused /mnt/private to get RELABELED with the private label of the --name=consumemounts container. Restarting mountsfromhere will cause it to get RELABELED again! $ docker start -ai mountsfromhere # exit $ ls -lZ /mnt system_u:object_r:svirt_sandbox_file_t:s0:c374,c495 private system_u:object_r:svirt_sandbox_file_t:s0 public So the moral of the story is the :z and :Z should ONLY be applied when the container is FIRST created. Not when the volume is used in a --volumes-from nor when a container is re-started....
Well the one I am testing against is working with the latest patches. docker run -ti --rm --volumes-from=mountsfromhere --name=consumemounts fedora /bin/bash [root@2492fa0bdd47 /]# cd /mnt/private/ bash: cd: /mnt/private/: Permission denied [root@2492fa0bdd47 /]#ls -lZ /mnt/ drwxr-xr-x. root root system_u:object_r:svirt_sandbox_file_t:s0:c54,c805 private drwxr-xr-x. root root system_u:object_r:svirt_sandbox_file_t:s0 public [root@2492fa0bdd47 /]# ps -eZ LABEL PID TTY TIME CMD system_u:system_r:svirt_lxc_net_t:s0:c99,c183 1 ? 00:00:00 bash system_u:system_r:svirt_lxc_net_t:s0:c99,c183 20 ? 00:00:00 ps I will have Lokesh build a new package on Tuesday for you to test.
Ok the bug I'm seeing is in Fedora and 1.6. I'm sorry, not RHEL 7 (accidentally selected instead of Fedora). And it's an older version (1.6). I will retest this when I get my hands on 1.7.x (I guess I thought Fedora 21 updated would have newer version than RHEL 7)
No one has 1.7 since it is just a release candidate from docker as of yesterday. It is available in Rawhide now.
Lokesh we need to get docker-1.6.2 build out for Fedora 22, 21 to see if we still have this problem.
dnf -y update docker --enablerepo=updates-testing