<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><div>I do start them as non-root user because I tough I was the only way to start an unprivileged container on the system. </div><div><br></div><div>benoit@lxd-virt-01a:~$ lxc-ls -f<br>NAME STATE IPV4 IPV6 GROUPS AUTOSTART<br>------------------------------------------------------<br>benoit RUNNING IP_ADDRESS - - NO<br>jordan STOPPED - - - NO<br></div><div><br data-mce-bogus="1"></div><div>benoit@lxd-virt-01a:~$ lxc-start -n jordan<br></div><div><br data-mce-bogus="1"></div><div>benoit@lxd-virt-01a:~$ /opt/deploy_lxc/add_lxc_flows.sh jordan<br>Adding FLOWS for jordan container<br>Trafic limited to 10Mb/s<br></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>benoit@lxd-virt-01a:~$ lxc-info -n jordan<br>Name: jordan<br>State: RUNNING<br>PID: 17994<br></div><div><br>Process:</div><div><br>benoit 10487 0.0 0.0 43512 3532 ? Ss août31 0:00 [lxc monitor] /LXC_DIR/benoit benoit<br>benoit 17982 0.0 0.0 43512 3576 ? Ss 01:53 0:00 [lxc monitor] /LXC_DIR/benoit jordan<br></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Each container on the system is a unix user. </div><div>They can all manage their own LXC container. Each one have an [lxc monitor] process</div><div><br>I do the provising as root (LVM storage) , including the mount of the specific rootfs for the container. </div><div>I will share soon all the scripts used . Deployment is automatic</div><div><br></div><div>The only one program used with an setuid is used to set the network flows. Sudo is an option to allow normal user to use it too.</div><div><br></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Quoting Benoit GEORGELIN - Association Web4all (benoit.georgelin@web4all.fr):<br></div><div data-marker="__QUOTED_TEXT__">> 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 . <br>> <br>> My design is this one , I use openvswitch for the newtorking <br>> <br>> log on the system as user : non-root <br><br>Why do you want to start them as non-root? Are you having other<br>people run them? You *can* start user-namespaced containers as<br>root, which is what I do to use encrypted lvm devices as backing<br>stores.</div><div data-marker="__QUOTED_TEXT__"><br></div><div data-marker="__QUOTED_TEXT__">> start your container: lxc-start -n unpriv-ubuntu <br>> <br>> - VethXXX is added to the bridge "br-container" <br>> <br>> The configuration of the virtual switch is blocking everything BUT what you allow with Openflows rules. <br>> So, to get a working network connection from the new container , I have to add some flows to openvswitch. <br>> <br>> The big thing is here, every time you shutdown the container, two things changes all the time : <br>> <br>> - veth name (vethxxxxx) <br>> - port number in openvswitch <br>> <br>> And, openflows rules are based on ... in_port <br>> <br>> This bring a lot of challenges that others people than me will get soon : <br>> <br>> - allow root setuid script that can be used by any lxc users to bring up the OpenFlow rules (every time I start a container) <br>> - script the cleanup of vethXXX in openvswitch because LXC add it but is not able to remove it (every time I stop a container) <br><br>Scripts can't run setuid-root. We'd have to do it through a program.<br><br>> - 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) <br>> <br>> This can be handle by hand if you start / stop container using the command line lxc tools : lxc-stop, lxc-start <br>> 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 ... <br>> <br>> 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 . <br>> <br>> 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 <br>> Maybe I'm totally wrong, or I'm missing something :) <br><br>The thing we don't want is to allow the unprivileged user to specify a script<br>to run as root :) But if we can come up with a program that is shipped with<br>lxc, that may be doable.<br><br>> I don't know how software like Openstack or Proxmox are integrating LXC Unprivileged container but they should talk/share more about it ^^ <br>> <br>> Regards, <br>> <br>> Cordialement, <br>> <br>> Benoît Georgelin <br>> <br>> De: "Serge Hallyn" <serge.hallyn@ubuntu.com> <br>> À: "lxc-users" <lxc-users@lists.linuxcontainers.org> <br>> Envoyé: Lundi 31 Août 2015 09:39:01 <br>> Objet: Re: [lxc-users] Unprivileged container and lxc.network.script.up <br>> <br>> Quoting Benoit GEORGELIN - Association Web4all (benoit.georgelin@web4all.fr): <br>> > Hi, <br>> > <br>> > I would like to know if there is an alternative option of lxc.network.script.up with an unprivileged containter. <br>> <br>> No. You'll need to start the container as root to do that - else you're <br>> allowing an unprivileged user to specify a script to run as root in the <br>> initial network namespace. <br>> <br>> -serge <br>> _______________________________________________ <br>> lxc-users mailing list <br>> lxc-users@lists.linuxcontainers.org <br>> http://lists.linuxcontainers.org/listinfo/lxc-users <br><br>> _______________________________________________<br>> lxc-users mailing list<br>> lxc-users@lists.linuxcontainers.org<br>> http://lists.linuxcontainers.org/listinfo/lxc-users<br><br>_______________________________________________<br>lxc-users mailing list<br>lxc-users@lists.linuxcontainers.org<br>http://lists.linuxcontainers.org/listinfo/lxc-users<br></div></div></body></html>