The "mysql" Docker image creates a volume on /var/lib/mysql inside the container. At runtime, the entrypoint script attempts to chown this directory to the mysql user, which leads to the following error: # docker run -e MYSQL_ROOT_PASSWORD=secret mysql FATAL ERROR: Could not chown directory /var/lib/mysql And the following AVC: type=AVC msg=audit(1416629737.562:201): avc: denied { setattr } for pid=22615 comm="mysql_install_d" name="d27cb6010a47942d7dc4826ebfe138ea62888fc9a5dedcaf14ebb3a1f45781c2" dev="dm-0" ino=6329484 scontext=system_u:system_r:svirt_lxc_net_t:s0:c190,c586 tcontext=system_u:object_r:docker_var_lib_t:s0 tclass=dir permissive=0 Which translates to: module docker 1.0; require { type svirt_lxc_net_t; type docker_var_lib_t; class dir setattr; } #============= svirt_lxc_net_t ============== allow svirt_lxc_net_t docker_var_lib_t:dir setattr; A simple reproducer is to create a Dockerfile with the following: FROM fedora VOLUME /var/lib/myvolume RUN chown nobody /var/lib/myvolume And attempt to "docker build .": Sending build context to Docker daemon 2.56 kB Sending build context to Docker daemon Step 0 : FROM fedora ---> 7d3f07f8de5f Step 1 : VOLUME /var/lib/myvolume ---> Running in 5f2e6a9a51e0 ---> ea49c8d042b2 Removing intermediate container 5f2e6a9a51e0 Step 2 : RUN chown nobody /var/lib/myvolume ---> Running in d1083d0ccc68 chown: changing ownership of '/var/lib/myvolume': Permission denied 2014/11/22 04:27:19 The command [/bin/sh -c chown nobody /var/lib/myvolume] returned a non-zero code: 1
Hmm, don't see this error on a vanilla fedora, sending over to atomic.
You have to label the /var/lib/mysql with the correct SELinux label chcon -t svirt_lxc_net_t -R /var/lib/mysql Which will fix the issue man docker run ... Mounting External Volumes To mount a host directory as a container volume, specify the absolute path to the directory and the absolute path for the container directory separated by a colon: # docker run -v /var/db:/data1 -i -t fedora bash When using SELinux, be aware that the host has no knowledge of container SELinux policy. Therefore, in the above example, if SELinux policy is enforced, the /var/db directory is not writable to the container. A "Permission Denied" message will occur and an avc: mes‐ sage in the host's syslog. To work around this, at time of writing this man page, the following command needs to be run in order for the proper SELinux policy type label to be attached to the host direc‐ tory: # chcon -Rt svirt_sandbox_file_t /var/db Now, writing to the /data1 volume in the container will be allowed and the changes will also be reflected on the host in /var/db.
I just ran into this issue myself, and unfortunately if Docker containers aren't meant to be able to write to files labeled docker_var_lib_t then the Project Atomic web site needs a correction. On http://www.projectatomic.io/docs/docker-and-selinux/ it clearly states that processes with svirt_lxc_net_t can write to either svirt_sandbox_file_t or docker_var_lib_t. The latter is necessary to use data volumes in their default location /var/lib/docker/volumes. If this isn't meant to be, then it would be useful to have a directory where the default context is svirt_sandbox_file_t (I couldn't find one) so that we can place Docker data volumes there.
We have fixed the latest docker to label these volumes correctly. And changed SELinux to block writing to docker_var_lib_t. Since most content under /var/lib/docker is docker_var_lib_t, it is pretty dangerous to allow containers to write any where under that directory. Michael, if you go to /var/lib/docker/vfs you could probably just run chcon there chcon -r -t svirt_sandbox_file_t . And that will fix your problem. I guess I could change the default policy to set that label.