[mk@xps x]$ getenforce Enforcing with docker-io-0.11.1-1.fc20.x86_64 : [mk@xps x]$ docker run --rm -v $PWD:/test hg-dockerrpm-fedora ls -l /test (as expected) with docker-io-0.11.1-3.fc20.x86_64 : [mk@xps x]$ docker run --rm -v $PWD:/test hg-dockerrpm-fedora ls -l /test ls: cannot open directory /test: Permission denied - but after setenforce 0 it works anyway. I also see https://bugzilla.redhat.com/show_bug.cgi?id=1096375 - they might be related or have the same root cause. Workaround: stick to 0.11.1-1
Currently if you add a directory via mount youhave to chcon -Rt svirt_sandbox_file_t /test I have sent a patch upstream to allow docker run --rm -v $PWD:/test:/test:Z hg-dockerrpm-fedora ls -l /test Which will label the content in /test with the correct label for the container.
Thanks. Nice to know a fix is coming. (I do not understand how it can be NOTABUG when it stopped working with a package update and a patch can fix it ... but a rose by any name ...) Do you have a link to the upstream patch? Is it SE upstream or docker?
Mads Not a bug because it is documented in the Man page. man docker-run ... When using SELinux, be aware that the host has no knowledge of con‐ tainer SELinux policy. Therefore, in the above example, if SELinux policy is enforced, the /var/db directory is not writable to the con‐ tainer. A "Permission Denied" message will occur and an avc: message 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 directory: # chcon -Rt svirt_sandbox_file_t /var/db Usability issue, perhaps. :^(