On 11/28/2015 4:19 PM, Neil Davies wrote: > I can confirm that this sis the problem > > There was a change in docker 1.2.1 (a CVE related fix) that now forces > /proc/fs to be mounted read-only > > use of the --privileged argument to docker run does allow openafs to run ok, > but only at the cost of loosing > all of the container isolation! > > I spent some time trying to work out how to _just_ permit read-write access > to the appropriate portion of > the /proc/fs filestore, but not cracked it. > > It is potentially possible to mount the host's /proc/fs/openafs under a > different name (with read-write access) > within the container - but that would imply a change to the openafs building > process.... > > Obviously I could modify the docker sources, submit a patch etc.. > > Any suggestions? I'm just wondering if there is any other bits of > functionality that the docker folks might have > broken this way - looking to see if there we, as a community, are not alone > here. > > Neil
Containers were not designed with the expectation that they would be accessing resources from a network file system. The solution that I am pursuing with Microsoft is to permit the container to be created with a network identity associated to it. For Linux what we would want is the ability to start a container and all of its processes as part of a PAG where a process running in the host context (not the container's) would obtain the tokens for the container. I believe it is inappropriate for the container processes to have access to a keytab or a username/password combination. I agree with Microsoft that a container should not be able to modify kernel driver state such as by storing a network credential for a remote user. There is no requirement that kernel drivers provide security boundaries between container name spaces. There are some use cases such as running an sshd that provides shells with access to network resources as the remote user identity which are not appropriate for Containers. Virtual machines should be used in such instances to obtain the proper process isolation. Jeffrey Altman
<<attachment: jaltman.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
