Ubuntu
linux package

Removal of CONFIG_NET_NS from 2.6.32-32 breaks applications

Bug #844185 reported by Alex Bligh
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Invalid
Undecided
Unassigned
Lucid
Won't Fix
Medium
Tim Gardner

Bug Description

LP #700295 removed CONFIG_NET_NS from linux-image-2.6.32-32 which was present in linux-image-2.6.32-31 and all previous versions (at least in the -server variant). The reason given is that destroying namespaces takes a large amount of time (this is true, and I believe is an RCU sync issue). If you create and delete a lot of namespaces, it can act as a DoS.

However, this breaks functionality for existing applications using LTS kernels and using namespaces in relatively static configurations (i.e. ones where non-root users cannot rapidly create and delete namespaces). This seems to me to be an unreasonable change, as LTS kernel changes are not meant to remove existing functionality. We have a production application (well, one week away from production) which suddenly broke due to this. As we are only using LTS for security updates etc., this is rather unfortunate, as we now cannot take any further kernel patches (unless this is reverted), which is rather the point of LTS.

Worse still, later kernels are WORSE in their stability for namespace configurations, so we cannot move to 2.6.38 (see LP #843892).

It seems to me a more appropriate fix to LP #700295 would have been to disable the use of network namespaces in vsftp, which would then leave existing users who do allow rapid cycling of namespaces to carry on regardless. This must be a trivial patch in vsftp as it must already cope with failure of the clone() syscall to support CLONE_NEWNS, as that's how it works on existing kernels.

See original description
Tags: lucid
Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 844185

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Leann Ogasawara (leannogasawara)
tags: added: lucid
Changed in linux (Ubuntu Lucid):
assignee: nobody → Canonical Kernel SRU Team (canonical-kernel-sru-team)
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Alex Bligh (ubuntu-alex-org) wrote : Re: Removal of CONFIG_NS from 2.6.32-32 breaks applications

See also #790863 - another application affected the same way.

Tim Gardner (timg-tpi)
summary: - Removal of CONFIG_NS from 2.6.32-32 breaks applications
+ Removal of CONFIG_NET_NS from 2.6.32-32 breaks applications
description: updated
Revision history for this message
Tim Gardner (timg-tpi) wrote :

I believe disabling CONFIG_NET_NS was the correct action for Lucid given its impact on some widely used applications. According to policy CONFIG_NET_NS should not have been enabled to begin with. Subsequent config reviews have been more rigorous. If you have a product that is dependent on this feature then lets figure out _why_ its not working. CONFIG_NET_NS was officially enabled beginning with Natty (2.6.38). Unfortunately, CONFIG_NET_NS is still incorrectly enabled in Maverick.

Changed in linux (Ubuntu Lucid):
assignee: Canonical Kernel SRU Team (canonical-kernel-sru-team) → Tim Gardner (timg-tpi)
status: Triaged → Won't Fix
Changed in linux (Ubuntu):
status: Incomplete → Invalid
Revision history for this message
Alex Bligh (ubuntu-alex-org) wrote :

The product is not working because it incorporates router(s) than runs in containers. The containers are necessary to provide proper isolation of the RIBs/FIBs, iptables, conntrack entries etc. Without the container, no routers, & no product. So we need a kernel that provides containers, as 2.6.32 did until it was disabled.

A reasonable resolution would be to use the Natty backport kernel (2.6.38); I presume that that has LTS support if it's in the Lucid repo (even if it's a backport)? The problem here is that we need LP #843892 fixed for that to work. I have supplied a patch which works.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.