CONFIG_NET_NS

[Tim Gardner]

On 06/01/2011 12:57 PM, Serge Hallyn wrote:
> Hi,
>
> vsftpd spawns a network namespace in response to each client connection.
> Lucid kernel is slow to release network namespaces, which results, in
> bug 720095, in an easy remote DOS.  The maverick kernel has a fix for
> this, but it is hard to cherrypick.
>
> The bug was resolved by compiling the lucid kernel without
> CONFIG_NET_NS.  I'm emailing to ask that we reconsider that solution.
>
> Turning off CONFIG_NET_NS prevents libvirt from creating all containers
> (lxc:///), and prevents lxc from creating most useful containers,
> resulting in bug 790863.  There is the workaround of installing the
> backported kernel, but I don't believe that will satiate users who
> really want LTS stability.  For those users, we are effectively telling
> them that they cannot use containers until 12/04.
>

What is wrong with suggesting the use of LTS backported kernels? The UDS 
decision to support these kernels until the next LTS should provide the 
same level of stability. We (the kernel team) are very much telling the 
community that network name spaces were not ready for prime time in 2.6.32.

> What I don't believe has been discussed is that CLONE_NEWNET requires
> privilege.  The vsftpd bug was bad because anyone could trigger it with
> a set of remote connections.  But that is easily fixed by patching
> vsftpd to not use CLONE_NEWNET.  As Stefan noted in irc, there is the
> threat that other services use CLONE_NEWNET.  Though I've grepped some
> of my local sources for samba, dhclient, postfix, apache, mysql, squid
> etc, and have found no others using CLONE_NEWNET so far.  That doesn't
> mean there aren't any, but I argue that the risk is far outweighed by
> not supporting containers in lucid.
>

It was decided that we should not regress a very common use case (or 
package) because of an experimental feature (which CONFIG_NET_NS was in 
2.6.32). We were also pretty sure we could not find every existing use 
of CLONE_NEWNET, nor prevent future uses of the feature.

> Thanks for your time :)
>
> thanks,
> -serge
>

rtg
-- 
Tim Gardner tim.gardner at canonical.com