Re: [lxc-users] macvlan-based networking for unprivileged containers
On Tue, Feb 24, 2015 at 11:50 AM, Serge Hallyn serge.hal...@ubuntu.com wrote: Quoting Fajar A. Nugraha (l...@fajar.net): On Wed, Feb 18, 2015 at 12:27 AM, Serge Hallyn serge.hal...@ubuntu.com wrote: Quoting Fajar A. Nugraha (l...@fajar.net): # c1's veth name on host side auto v-c1-0 iface v-c1-0 inet static I'm probably just ignorant here, but - does this not cause 'ifup -a' to fail when the containers are not up? ifup throws an error message, but still exit with code 0, so it should be safe. udev and network-interface service will kick in to automatically activate it when the interface becomes available (i.e. when the container is started) # ifup -a;echo $? Cannot find device v-c1-0 Failed to bring up v-c1-0. 0 # ifup v-c1-0;echo $? Cannot find device v-c1-0 Failed to bring up v-c1-0. 0 Agreed it sounds like a very useful setup. Any chance you would have time to write the needed extensions for lxc-user-nic? Not anytime immediate, but possibly some time in the next month. Here's what I propose: (1) update lxc-user-nic and lxc-start(?) so that: - when lxc.network.link is not specified on lxc config file, it will pass none as bridge name to lxc-user-nic - lxc-user-nic does not actually add the interface to any bridge when bridge parameter is none, so that /etc/lxc/lxc-usernet can have entries like this # USERNAME TYPE BRIDGE COUNT user veth lxcbr0 10 user veth none 10 This one should be pretty straight forward and easiest to implement (2) Allow custom veth name on the host side. The best way I can think of is to add one more parameters to lxc-user-nic. Currently: $ /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic Usage: /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic pid type bridge nicname nicname is the name to use inside the container ... will become Usage: /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic pid type bridge nicname [pairname] nicname is the name to use inside the container. pairname is the name to use for the veth pair on the host, only valid when type is veth. If pairname is empty, veth pair name will be autogenerated. We also add /etc/lxc/lxc-usernet-veth-pairname, which will be used by lxc-usernet when pairname is not empty, and has this format # USERNAME PAIRNAME(15 chars max) user veth-user-c1-0 user veth-user-c2-0 user veth-user-c2-1 user2 veth-user2-c1-0 user2 veth-user2-c2-0 As an alternative, you could also only enforce the prefix, so that the format becomes like this # USERNAME PAIRNAME_PREFIX user veth-user- user2 veth-user2- In both cases, the nic count is enforced by /etc/lxc/lxc-usernet, and /etc/lxc/lxc-usernet-veth-pairname is only used to enforce veth pair name compliance. (3) sometime in the future: add support for lxc.network.type=proxyarp It would create veth nic, and does the configuration on the host side (enable proxyarp, setup ip including its pointopoint pair) and the container side. When using lxc.network.type=proxyarp: - lxc.network.link is used to specify which host interface will have proxyarp enabled (eth0 in my previous example) - lxc.network.ipv4 is used to specify IP on the container side (192.168.124.251 in my previous example) - lxc.network.ipv4.gateway is used to specify pointopoint IP on the host side (which is also used as gateway inside the container). On my example I used 172.16.0.1. We could probably assign 169.254.1.1 (a link-local address) as the default IP to use when this config item is not set. Are you ok with that design? -- Fajar ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] macvlan-based networking for unprivileged containers
Quoting Fajar A. Nugraha (l...@fajar.net): On Wed, Feb 18, 2015 at 12:27 AM, Serge Hallyn serge.hal...@ubuntu.com wrote: Quoting Fajar A. Nugraha (l...@fajar.net): # c1's veth name on host side auto v-c1-0 iface v-c1-0 inet static I'm probably just ignorant here, but - does this not cause 'ifup -a' to fail when the containers are not up? ifup throws an error message, but still exit with code 0, so it should be safe. udev and network-interface service will kick in to automatically activate it when the interface becomes available (i.e. when the container is started) # ifup -a;echo $? Cannot find device v-c1-0 Failed to bring up v-c1-0. 0 # ifup v-c1-0;echo $? Cannot find device v-c1-0 Failed to bring up v-c1-0. 0 Agreed it sounds like a very useful setup. Any chance you would have time to write the needed extensions for lxc-user-nic? ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] macvlan-based networking for unprivileged containers
On Wed, Feb 18, 2015 at 12:27 AM, Serge Hallyn serge.hal...@ubuntu.com wrote: Quoting Fajar A. Nugraha (l...@fajar.net): # c1's veth name on host side auto v-c1-0 iface v-c1-0 inet static I'm probably just ignorant here, but - does this not cause 'ifup -a' to fail when the containers are not up? ifup throws an error message, but still exit with code 0, so it should be safe. udev and network-interface service will kick in to automatically activate it when the interface becomes available (i.e. when the container is started) # ifup -a;echo $? Cannot find device v-c1-0 Failed to bring up v-c1-0. 0 # ifup v-c1-0;echo $? Cannot find device v-c1-0 Failed to bring up v-c1-0. 0 -- Fajar ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] macvlan-based networking for unprivileged containers
Quoting Serge Hallyn (serge.hallyn at ubuntu.com): On Thu Feb 12, 2015 at 11:18 Fajar A. Nugraha list at fajar.net wrote: On Thu, Feb 12, 2015 at 5:29 PM, Purcareata Bogdan b43198 at freescale.com wrote: On 10.02.2015 19:22, Christian Brauner wrote: Hello, is it currently possible to use macvlan interfaces with unprivileged containers? +1 I noticed too that it wasn't possible. This might a limitation of the user namespace itself, since the lower device you're attaching to is still in the host / root namespace, and you don't have access to that as a normal user. What I often ask, is WHY? Yes, macvlan does not work for unpriv containers. However veth works just fine. And you don't have to put your public link (e.g. eth0) on bridge mode to have a working container with veth network. FWIW what it would take is an extension to lxc-user-nic to support (accounted) unpriv macvlan. /etc/lxc/lxc-usernet would then support something like $user macvlan eth0 10. But as Fajar says, the value of this seems dubious, and I'm not sure whether that would have the same snooping-on-same-link concerns that you'd have with a bridged eth0. Is there presently a way to block network traffic between unprivileged containers, or between a container and the host? This could be desirable when running untrusted containers. According to http://containerops.org/2013/11/19/lxc-networking , macvlan private mode disallows any communication between lxc containers, hence macvlan might be useful for untrusted containers. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] macvlan-based networking for unprivileged containers
Quoting overlay fs (overla...@gmail.com): Quoting Serge Hallyn (serge.hallyn at ubuntu.com): On Thu Feb 12, 2015 at 11:18 Fajar A. Nugraha list at fajar.net wrote: On Thu, Feb 12, 2015 at 5:29 PM, Purcareata Bogdan b43198 at freescale.com wrote: On 10.02.2015 19:22, Christian Brauner wrote: Hello, is it currently possible to use macvlan interfaces with unprivileged containers? +1 I noticed too that it wasn't possible. This might a limitation of the user namespace itself, since the lower device you're attaching to is still in the host / root namespace, and you don't have access to that as a normal user. What I often ask, is WHY? Yes, macvlan does not work for unpriv containers. However veth works just fine. And you don't have to put your public link (e.g. eth0) on bridge mode to have a working container with veth network. FWIW what it would take is an extension to lxc-user-nic to support (accounted) unpriv macvlan. /etc/lxc/lxc-usernet would then support something like $user macvlan eth0 10. But as Fajar says, the value of this seems dubious, and I'm not sure whether that would have the same snooping-on-same-link concerns that you'd have with a bridged eth0. Is there presently a way to block network traffic between unprivileged containers, or between a container and the host? This could be desirable when running untrusted containers. You (your administrator) could create separate bridges for each user. -serge ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] macvlan-based networking for unprivileged containers
On 10.02.2015 19:22, Christian Brauner wrote: Hello, is it currently possible to use macvlan interfaces with unprivileged containers? +1 I noticed too that it wasn't possible. This might a limitation of the user namespace itself, since the lower device you're attaching to is still in the host / root namespace, and you don't have access to that as a normal user. I would be very interested to know if macvlan could supported with unprivileged containers, and what kind of work would be necessary to make that happen. Thanks, Bogdan P. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
