Cockpit as a privileged container?

Daniel J Walsh dwalsh at redhat.com
Mon Aug 4 19:49:48 UTC 2014


On 08/04/2014 03:34 PM, Daniel J Walsh wrote:
> On 08/01/2014 09:45 AM, Trevor Jay wrote:
>> On Fri, Aug 01, 2014 at 06:26:03AM -0400, Daniel J Walsh wrote:
>>> We have kicked around the idea of a "Super Priv container" where you
>>> could switch to a limited number of namespaces.  
>>>
>> If the number of namespaces we want to support switching to is limited and --privileged containers run with a different type (docker_t) from others (svirt_lxc_net_t), do you really need upstream Docker support? Terrible idea: couldn't we take the same approach we do with service and have an executable for each namespace we want? These "entry points" only purpose would be to provide a transition point from docker_t? Combined with:
>>
>>     -v /var/..:/host --net="host"
>>
>> such a container would only have to know to where to expect the mount point and the directory of "namespace entry points".
>>
>> Taking this approach, I was able to get a container with an unmunged network, access to the host /, and able to spawn processes running as unconfined_t. That (or less) seems sufficient for cockpit given a few modifications.
>>
>> Granted, real --namespace-add and --namespace-drop support would be less of a sin against god and man... but this would allow for experimentation right now.
>>
>> _Trevor
>>
> That looks good, except you don't have /proc shared.
>
> This works for me on newer docker.
>
> docker run --rm -v /:/host -ti --net=host --privileged fedora /bin/sh
>
> I was thinking of doing this with /sysimage, but maybe /host is a better
> name.
>
>
>
> _______________________________________________
> cockpit-devel mailing list
> cockpit-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/cockpit-devel
Of course you can chroot /host and then be in a container on the host. 
But you loose view of your executables in your own mount.



More information about the cockpit-devel mailing list