Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
readonly root inside container #7923
Fedora has supported the concept of a readonly root for a long time as way of making a system more stateless.
We have used this with boot-from-initramfs deployments to make sure that no service accidentally writes somewhere it shouldn't. I think this could also be useful within containers to make sure that services that run in the container are properly configured to either write data to tmpfs-backed temporary directories or to r/w volumes shared from outside with --volume and nowhere else.
The main Fedora script is here: https://git.fedorahosted.org/cgit/initscripts.git/tree/systemd/fedora-readonly
A writeup of how it works: https://warewolf.github.io/blog/2013/10/12/setting-up-a-read-only-rootfs-fedora-box/
In a Docker context, I think the main things that would carry over are flags for docker run:
Does this sound like something that's interesting to support in Docker? If so, I could start looking at putting together the start of a pull request.
I am +1 for this and it's already able to be supported in libconatiner.
Do you think we need to have the ability to specify tmpfs mounts first though via docker before we can do this? There will be some applications that need to write in
I think you can take care of passing the equivalent of Fedora's RW_MOUNT=/var/lib/stateless/writable and STATE_MOUNT=/var/lib/stateless/state through to the container using --volume flags.
There's still some configuration required. I think this is probably something that should go in the Dockerfile, but maybe people want to be able to change their minds at docker run time.
Taking a look at Fedora's rwtab today, you have 3 types of configuration:
dirs means take all the directories in the base image and make them available for read/write, either on top of a tmpfs or on top of the RW_MOUNT directory.
empty means the same for the directory, but ignore any subdirectories that might exist in the base image.
files gives you a read/write file with the initial contents from the image.
So if you do this in the Dockerfile, each of these might become a RWTAB line (need a better name) you'd also have a RW_MOUNT specifying a directory, where if it isn't set, means you get a tmpfs.
And then maybe docker run takes a --rwmount flag. Maybe you also need to be able to do rwtab entries on the command line. Maybe --rw-dir --rw-empty --rw-files?
From my perspective, the main reason it's nice to have this in the Dockerfile is that it simplifies the arguments needed to get one of these containers running with the right rw and state mounts and rwtab entries, without changing anything in the Mesos API for running Docker containers.