[lxc-users] macvlan-based networking for unprivileged containers

overlay fs overlayfs at gmail.com
Fri Feb 13 11:19:44 UTC 2015


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.


More information about the lxc-users mailing list