[lxc-devel] [PATCH 1/1] Fix unprivileged networking

[Stéphane Graber]

On Tue, Feb 18, 2014 at 04:32:02PM -0600, Serge Hallyn wrote:
> Quoting Stéphane Graber (stgraber at ubuntu.com):
> > On Tue, Feb 18, 2014 at 04:19:58PM -0600, Serge Hallyn wrote:
> > > Quoting Stéphane Graber (stgraber at ubuntu.com):
> > > > On Tue, Feb 18, 2014 at 03:12:52PM -0600, Serge Hallyn wrote:
> > > > > If we are unprivileged and have asked for a veth device, then create
> > > > > a pipe over which to pass the veth names.
> > > > > 
> > > > > Network-related todos:
> > > > > 1. set mtu on the container side of veth device
> > > > 
> > > > > 2. set mtu in lxc-user-nic.  Note that this probably requires an
> > > > >    update to the /etc/lxc/lxc-usernet file :(
> > > > 
> > > > Hmm, that's an interesting problem and even without that change, we
> > > > actually have a bug at the moment which may or may not qualify as a
> > > > security issue.
> > > > 
> > > > The bridge will set its own MTU to the lowest of all devices inside it
> > > > (or so it looks like anyway), so say that a bridge has an MTU of 9000
> > > > (jumbo) and a user can join a container to it, that'll decrease the MTU
> > > > to 1500 possibly breaking the other containers in the bridge.
> > > > 
> > > > To fix that it looks like we indeed want an extra column in lxc-usernet
> > > > which would specify the min and max MTU, a value of 0 (same as no value)
> > > > would tell lxc-user-nic to copy that of the bridge, an value of
> > > > 1500:4000 would mean that the mtu may not be set below 1500 or above
> > > > 4000.
> > > > 
> > > > Unfortunately as this would result in a rather user visible change as
> > > > well as documentation changes, if we are going to do this, we really
> > > > should do it before 1.0.
> > > > 
> > > > 
> > > > Alternatively we could state that unprivileged containers may not use a
> > > > custom MTU and that they will always default to the bridge's MTU value
> > > > for both sides of the veth device.
> > > > 
> > > > In which case we still need to change both lxc and lxc-user-nic to get
> > > > the current MTU from the bridge and set it on both side of the veth
> > > > device.
> > > 
> > > Does lxc need to do it?  We should just be able to have lxc-user-nic
> > > copy the bridge's value right?
> > 
> > We probably would want to make sure that the behaviour is consistent and
> > that if lxcbr0 has a mtu of say 1400 that both veth also get an mtu of
> > 1400 in the system container case too.
> > 
> > But yes, for the unprivileged case, we could simply have lxc-user-nic
> > set the mtu to the bridge's value on both devices of the veth pair.
> 
> Which should be enough for 1.0 (was my point) ?
> 
> I'm ok with your longer solution too, but that's a big change for
> last-minute.

Right, I'd be fine with us just having:
 - lxc discard lxc.network.mtu for unpriv containers
 - lxc-user-nic mirror the bridge mtu to both interfaces of the veth pair
 - ensure that privileged lxc will always set the same mtu on both
   interfaces in a veth pair

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20140218/3f7b64cf/attachment.pgp>