follow up of #19876

SGTM, although not sure what difference SELinux makes in this

@thaJeztah SELinux code in libcontainer was attempting to set the SELinux label on the /dev/mqueue directory, when it is read/only this call fails, and causes the container to blow up.

@rhatdan ah, yes, didn't think of that, thx for explaining

I think this makes sense, so LGTM

LGTM

A little confused. Anything that is expecting to be able to write but can't is going to blow up regardless of where/what it's going to.

The idea of --read-only is to protect the container image from being rewritten. For example a hacker breaks into apache and then rewrites a backdoor by overriting /usr/bin/httdp. Any devices/file systems that are not saved on disk like tmpfs and shm should not be marked as --read-only. /dev/mqueue is the same, every time you start and stop the container, the contents of /dev/mqueue will be lost. So no reason to mark it readonly.

Another way to think about this would be to state that the COW file system is read-only any other file systems mounted into the container should continue to be writable by the processes in the container. Marking /dev as read/only, I think is also a mistake, but most processes would not need to write there.

I would like to get to the state where the default behaviour of containers in production is something like

docker run -d --tmpfs /run --tmpfs /tmp -v /MYVAR:/var --readonly FOOBAR

I believe this would be a much more secure way of running things in production.

http://www.projectatomic.io/blog/2015/12/making-docker-images-write-only-in-production/

Fine. LGTM.