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 [email protected]
--
ubuntu-server mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
