Future directions for Fedora Cloud

Daniel J Walsh dwalsh at redhat.com
Tue Sep 17 12:52:33 UTC 2013

Hash: SHA1

On 09/16/2013 04:57 PM, Colin Walters wrote:
> On Wed, 2013-09-11 at 12:01 -0400, Matthew Miller wrote:
>> So, idea one is to make something like CoreOS (http://coreos.com/): a 
>> lightweight distribution made for running containers on top of. We
>> wouldn't attempt to be _as_ lightweight as CoreOS (for that, there's
>> CoreOS), but aim to be small while still providing key features like
>> SELinux.
> How SELinux would work in a coreos/container deployment setup is an 
> interesting question.  One could imagine docker containers coming with 
> policy modules, but that ends up tying them to a specific host version, 
> which is kind of against the point of containers.
> More realistically I think one would have a relatively permissive domain 
> (generic_container_t), and use something like MCS labels to restrict the 
> flow of information between containers and the host.
Currently that is what we do with virt-sandbox containers.  svirt_lxc_net_t
and svirt_qemu_net_t is very loose, Full Network, Full Capabilities,
Read/Execute everything in /usr and most of /etc, no access to content in
/root, /home, /var (We bind mount containers content over /root, /home, and
/var)  And separate them from MCS.  They are only allowed to write to

I have setup the policy to allow policy writers to create limited network
privs container domains, fairly easily.  Perhaps we should do the same for

One concept I have built for OpenShift is the idea of an Admin of a container
versus the application within the container.  So a user joining a container
might have full access to all file types owned by the container, but the
applicagtion/service within the container would only be allowed to write to
the svirt_sandbox_file_rw_t content and read/exec svirt_sandbox_file_t content.

>> Perhaps this could be built with Colin Walter's OSTree (see 
>> https://wiki.gnome.org/OSTree) for atomic updates.
> To follow up on this, I have been working slowly on this tool called 
> "yum-ostree" which is designed to capture packages as OSTree commits. At
> the moment it's just a lame python script, but it's nearly to the point of
> being useful.  I'll post to the generic fedora-devel-list when it's ready.
> As far as OSTree compared to CoreOS; the biggest difference is that the 
> CoreOS updater mandates a particular filesystem chosen on the build server,
> because it sends block-level diffs.  OSTree operates at the filesystem
> layer (like rsync), and this allows more flexibility.  (At the moment
> though, OSTree is significantly less efficient on the network side).
> _______________________________________________ cloud mailing list 
> cloud at lists.fedoraproject.org 
> https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of
> Conduct: http://fedoraproject.org/code-of-conduct

Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


More information about the cloud mailing list