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