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

Tue Sep 1 00:20:24 UTC 2015

I do start them as non-root user because I tough I was the only way to start an unprivileged container on the system. 

benoit at lxd-virt-01a:~$ lxc-ls -f 
NAME STATE IPV4 IPV6 GROUPS AUTOSTART 
------------------------------------------------------ 
benoit RUNNING IP_ADDRESS - - NO 
jordan STOPPED - - - NO 

benoit at lxd-virt-01a:~$ lxc-start -n jordan 

benoit at lxd-virt-01a:~$ /opt/deploy_lxc/add_lxc_flows.sh jordan 
Adding FLOWS for jordan container 
Trafic limited to 10Mb/s 

benoit at lxd-virt-01a:~$ lxc-info -n jordan 
Name: jordan 
State: RUNNING 
PID: 17994 

Process: 

benoit 10487 0.0 0.0 43512 3532 ? Ss août31 0:00 [lxc monitor] /LXC_DIR/benoit benoit 
benoit 17982 0.0 0.0 43512 3576 ? Ss 01:53 0:00 [lxc monitor] /LXC_DIR/benoit jordan 

Each container on the system is a unix user. 
They can all manage their own LXC container. Each one have an [lxc monitor] process 

I do the provising as root (LVM storage) , including the mount of the specific rootfs for the container. 
I will share soon all the scripts used . Deployment is automatic 

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. 

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 

_______________________________________________ 
lxc-users mailing list 
lxc-users at lists.linuxcontainers.org 
http://lists.linuxcontainers.org/listinfo/lxc-users 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20150901/38a43301/attachment-0001.html>