[lxc-users] Unprivileged container and lxc.network.script.up

[Serge Hallyn]

Quoting Benoit GEORGELIN - Association Web4all (benoit.georgelin at web4all.fr):
> unfortunately, it's the only way to allow custom network configuration from an unprivileged exactly how lxc add the network interface into the Ovs switch . 
> 
> My design is this one , I use openvswitch for the newtorking 
> 
> log on the system as user : non-root 

Why do you want to start them as non-root?  Are you having other
people run them?  You *can* start user-namespaced containers as
root, which is what I do to use encrypted lvm devices as backing
stores.

> start your container: lxc-start -n unpriv-ubuntu 
> 
> - VethXXX is added to the bridge "br-container" 
> 
> The configuration of the virtual switch is blocking everything BUT what you allow with Openflows rules. 
> So, to get a working network connection from the new container , I have to add some flows to openvswitch. 
> 
> The big thing is here, every time you shutdown the container, two things changes all the time : 
> 
> - veth name (vethxxxxx) 
> - port number in openvswitch 
> 
> And, openflows rules are based on ... in_port 
> 
> This bring a lot of challenges that others people than me will get soon : 
> 
> - allow root setuid script that can be used by any lxc users to bring up the OpenFlow rules (every time I start a container) 
> - script the cleanup of vethXXX in openvswitch because LXC add it but is not able to remove it (every time I stop a container) 

Scripts can't run setuid-root.  We'd have to do it through a program.

> - script the cleanup of flow rules in openvswitch because the in_port previously used by the vethXXXX has been delete and will not be the same at a new boot. (every time I stop the container) 
> 
> This can be handle by hand if you start / stop container using the command line lxc tools : lxc-stop, lxc-start 
> But there is no way a container will have its network back with an init 6 command witch generate a new vethXXXX , a new port AND it leave the other interface UP on the HOST ... 
> 
> So, I'm not saying there is a simple solution here.. but I think we should make those things much more easier for people who wants to have more complex configuration . 
> 
> Unprivileged containers are amazing, technology is great , but to me, the work I did for the past two weeks is insane to have a fully working (and secure) LXC environment to brings up containers 
> Maybe I'm totally wrong, or I'm missing something :) 

The thing we don't want is to allow the unprivileged user to specify a script
to run as root :)  But if we can come up with a program that is shipped with
lxc, that may be doable.

> I don't know how software like Openstack or Proxmox are integrating LXC Unprivileged container but they should talk/share more about it ^^ 
> 
> Regards, 
> 
> Cordialement, 
> 
> Benoît Georgelin 
> 
> De: "Serge Hallyn" <serge.hallyn at ubuntu.com> 
> À: "lxc-users" <lxc-users at lists.linuxcontainers.org> 
> Envoyé: Lundi 31 Août 2015 09:39:01 
> Objet: Re: [lxc-users] Unprivileged container and lxc.network.script.up 
> 
> Quoting Benoit GEORGELIN - Association Web4all (benoit.georgelin at web4all.fr): 
> > Hi, 
> > 
> > I would like to know if there is an alternative option of lxc.network.script.up with an unprivileged containter. 
> 
> No. You'll need to start the container as root to do that - else you're 
> allowing an unprivileged user to specify a script to run as root in the 
> initial network namespace. 
> 
> -serge 
> _______________________________________________ 
> lxc-users mailing list 
> lxc-users at lists.linuxcontainers.org 
> http://lists.linuxcontainers.org/listinfo/lxc-users 

> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users