Quoting Benoit GEORGELIN - Association Web4all ([email protected]): > 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" <[email protected]> > À: "lxc-users" <[email protected]> > 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 ([email protected]): > > 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 > [email protected] > http://lists.linuxcontainers.org/listinfo/lxc-users > _______________________________________________ > lxc-users mailing list > [email protected] > http://lists.linuxcontainers.org/listinfo/lxc-users _______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
