ipv4: in new netns initialize sysctls in net.ipv4.conf.* with defaults
Subsystems (3)
PATCH 1/1 ipv4: in new netns initialize sysctls in net.ipv4.conf.* with defaults
Currently initial net.ipv4.conf.all.* and net.ipv4.conf.default.* are copied from init network namespace because static structures are used for init_net. This makes no sense because new netns might be created from any netns. This patch makes private copy also for init netns if network namespaces are enabled. Other sysctls in net.ipv4 and net.ipv6 already initialized with default values at namespace creation.
--- net/ipv4/devinet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv4/devinet.c +1 -1
@@ -2290,7 +2290,7 @@ static __net_init int devinet_init_net(struct net *net) all = &ipv4_devconf; dflt = &ipv4_devconf_dflt; -if (!net_eq (net, &init_net)) { +if (IS_ENABLED (CONFIG_NET_NS )) { all =kmemdup (all,sizeof (ipv4_devconf),GFP_KERNEL );if (!all) goto err_alloc_all;
Konstantin,
I've investigated question with sysctls initialization inside namespaces some time ago. IIRC I've found people expect that sysctl values should be inherited from parent namespace. It allows node admin to adjust unsafe pre-compiled settings, and prepare adequate defaults before creation of namespaces.
However, there is corner case:
module with sysctl can be loaded after creation of namespaces. In this case namespaces will get pre-compiled sysctl defaults, and are not be able to adjust them even if they want to do it.
Thank you,
Vasily Averin
Quoted 28 lines · Konstantin Khlebnikov
Currently initial net.ipv4.conf.all.* and net.ipv4.conf.default.* are copied from init network namespace because static structures are used for
init_net. This makes no sense because new netns might be created from any netns. This patch makes private copy also for init netns if network namespaces are enabled. Other sysctls in net.ipv4 and net.ipv6 already initialized with default values at namespace creation.Signed-off-by Konstantin Khlebnikov <[email protected]>Fixes 752d14dc6aa9 ("[IPV4]: Move the devinet pointers on the struct net")--- net/ipv4/devinet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)net/ipv4/devinet.c +1
-1@@ -2290,7 +2290,7 @@ static __net_init int devinet_init_net(struct net *net) all = &ipv4_devconf; dflt = &ipv4_devconf_dflt; -if (!net_eq (net, &init_net)) { +if (IS_ENABLED (CONFIG_NET_NS )) { all =kmemdup (all,sizeof (ipv4_devconf),GFP_KERNEL );if (!all) goto err_alloc_all;
Quoted 5 lines · Vasily Averin
Konstantin,
I've investigated question with sysctls initialization inside namespaces some time ago. IIRC I've found people expect that sysctl values should be inherited from parent namespace. It allows node admin to adjust unsafe pre-compiled settings, and prepare adequate defaults before creation of namespaces.
Only few sysctls are handled in this manner and they are copied from host, not parent. This works somehow for flat containers, as soon as you go deeper this turns into madness. Default settings must be controlled by software who creates namespaces. For now it must reset all yet-not-known sysctls into sane defaults.
BTW two ipv6 sysctl are special: net.ipv6.conf.default.disable_ipv6 and net.ipv6.conf.default.autoconf their defaults are controlled by module parameters and inherited by all namespaces. And this makes sense.
Quoted 38 lines
However, there is corner case:
module with sysctl can be loaded after creation of namespaces. In this case namespaces will get pre-compiled sysctl defaults, and are not be able to adjust them even if they want to do it.Thank you,
Vasily AverinQuoted 28 lines · Konstantin Khlebnikov
Currently initial net.ipv4.conf.all.* and net.ipv4.conf.default.* are copied from init network namespace because static structures are used for
init_net. This makes no sense because new netns might be created from any netns. This patch makes private copy also for init netns if network namespaces are enabled. Other sysctls in net.ipv4 and net.ipv6 already initialized with default values at namespace creation.Signed-off-by Konstantin Khlebnikov <[email protected]>Fixes 752d14dc6aa9 ("[IPV4]: Move the devinet pointers on the struct net")--- net/ipv4/devinet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)net/ipv4/devinet.c +1
-1@@ -2290,7 +2290,7 @@ static __net_init int devinet_init_net(struct net *net) all = &ipv4_devconf; dflt = &ipv4_devconf_dflt; -if (!net_eq (net, &init_net)) { +if (IS_ENABLED (CONFIG_NET_NS )) { all =kmemdup (all,sizeof (ipv4_devconf),GFP_KERNEL );if (!all) goto err_alloc_all;
Signature · 1 line
Konstantin
Quoted 6 lines · Konstantin Khlebnikov
Currently initial net.ipv4.conf.all.* and net.ipv4.conf.default.* are copied from init network namespace because static structures are used for
init_net. This makes no sense because new netns might be created from any netns. This patch makes private copy also for init netns if network namespaces are enabled. Other sysctls in net.ipv4 and net.ipv6 already initialized with default values at namespace creation.
Assuming that this does not cause a regression I am all for this, as it makes the kernels behavior predictable.
When creating a network namespace we have two predictable choices. Copy from the current network namespace, or initialize all sysctl values with the kernel's defaults. Copying values looks like a way to introduce subtle hard to debug breakage into existing setups. So all else being equal my preference is that we initialize values in new nework namespaces to their initial defaults.
Quoted 19 lines
Signed-off-by Konstantin Khlebnikov <[email protected]>Fixes 752d14dc6aa9 ("[IPV4]: Move the devinet pointers on the struct net")--- net/ipv4/devinet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)net/ipv4/devinet.c +1
-1@@ -2290,7 +2290,7 @@ static __net_init int devinet_init_net(struct net *net) all = &ipv4_devconf; dflt = &ipv4_devconf_dflt; -if (!net_eq (net, &init_net)) { +if (IS_ENABLED (CONFIG_NET_NS )) { all =kmemdup (all,sizeof (ipv4_devconf),GFP_KERNEL );if (!all) goto err_alloc_all;
Quoted 6 lines · Konstantin Khlebnikov
Currently initial net.ipv4.conf.all.* and net.ipv4.conf.default.* are copied from init network namespace because static structures are used for
init_net. This makes no sense because new netns might be created from any netns. This patch makes private copy also for init netns if network namespaces are enabled. Other sysctls in net.ipv4 and net.ipv6 already initialized with default values at namespace creation.
Assuming that this does not cause a regression I am all for this, as it makes the kernels behavior predictable.
When creating a network namespace we have two predictable choices. Copy from the current network namespace, or initialize all sysctl values with the kernel's defaults. Copying values looks like a way to introduce subtle hard to debug breakage into existing setups. So all else being equal my preference is that we initialize values in new nework namespaces to their initial defaults.
Quoted 19 lines
Signed-off-by Konstantin Khlebnikov <[email protected]>Fixes 752d14dc6aa9 ("[IPV4]: Move the devinet pointers on the struct net")--- net/ipv4/devinet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)net/ipv4/devinet.c +1
-1@@ -2290,7 +2290,7 @@ static __net_init int devinet_init_net(struct net *net) all = &ipv4_devconf; dflt = &ipv4_devconf_dflt; -if (!net_eq (net, &init_net)) { +if (IS_ENABLED (CONFIG_NET_NS )) { all =kmemdup (all,sizeof (ipv4_devconf),GFP_KERNEL );if (!all) goto err_alloc_all;
David Miller
maintainerFrom: Konstantin Khlebnikov <[email protected]>
Date: Sun, 21 Feb 2016 10:11:02 +0300
Quoted 9 lines
Currently initial net.ipv4.conf.all.* and net.ipv4.conf.default.* are copied from init network namespace because static structures are used for
init_net. This makes no sense because new netns might be created from any netns. This patch makes private copy also for init netns if network namespaces are enabled. Other sysctls in net.ipv4 and net.ipv6 already initialized with default values at namespace creation.Signed-off-by Konstantin Khlebnikov <[email protected]>Fixes 752d14dc6aa9 ("[IPV4]: Move the devinet pointers on the struct net")
The horse has long left the stable on this. We cannot change this now without breaking things.
Imagine someone who intentionally sets up init_net with a certain set of settings and expects them to propagate into every created namespace.
We'll break things for them and given the behavior existed for so long what the administrator is doing is very reasonable.
I'm not applying this sorry, we are stuck with the current behavior whether we like it or not.
Quoted 16 lines · David Miller
From: Konstantin Khlebnikov <[email protected]>
Date: Sun, 21 Feb 2016 10:11:02 +0300Quoted 9 lines
Currently initial net.ipv4.conf.all.* and net.ipv4.conf.default.* are copied from init network namespace because static structures are used for
init_net. This makes no sense because new netns might be created from any netns. This patch makes private copy also for init netns if network namespaces are enabled. Other sysctls in net.ipv4 and net.ipv6 already initialized with default values at namespace creation.Signed-off-by Konstantin Khlebnikov <[email protected]>Fixes 752d14dc6aa9 ("[IPV4]: Move the devinet pointers on the struct net")The horse has long left the stable on this. We cannot change this now without breaking things.
Quoted 8 lines
Imagine someone who intentionally sets up
init_netwith a certain set of settings and expects them to propagate into every created namespace.We'll break things for them and given the behavior existed for so long what the administrator is doing is very reasonable.
I'm not applying this sorry, we are stuck with the current behavior whether we like it or not.
Major kernel upgrades always break something in weird setups. This shouldn't block bug fixing.
This kludge works only for several ipv4 sysctls. If software or man ever have tried to setup ipv6 or tune tcp and want some non-default setup then it/he already knows that sysctls must be configured inside.
David Miller
maintainerFrom: Konstantin Khlebnikov <[email protected]>
Date: Wed, 24 Feb 2016 08:16:59 +0300
Quoted 2 lines
Major kernel upgrades always break something in weird setups. This shouldn't block bug fixing.
A bug for you is a feature for another person. I'm standing by my position, and will not apply this and break existing setups, sorry.
Quoted 16 lines · David Miller
From: Konstantin Khlebnikov <[email protected]>
Date: Sun, 21 Feb 2016 10:11:02 +0300Quoted 9 lines
Currently initial net.ipv4.conf.all.* and net.ipv4.conf.default.* are copied from init network namespace because static structures are used for
init_net. This makes no sense because new netns might be created from any netns. This patch makes private copy also for init netns if network namespaces are enabled. Other sysctls in net.ipv4 and net.ipv6 already initialized with default values at namespace creation.Signed-off-by Konstantin Khlebnikov <[email protected]>Fixes 752d14dc6aa9 ("[IPV4]: Move the devinet pointers on the struct net")The horse has long left the stable on this. We cannot change this now without breaking things.
Quoted 8 lines
Imagine someone who intentionally sets up
init_netwith a certain set of settings and expects them to propagate into every created namespace.We'll break things for them and given the behavior existed for so long what the administrator is doing is very reasonable.
I'm not applying this sorry, we are stuck with the current behavior whether we like it or not.
Dave I won't argue that the patch reaches the proper trade-off with existing software. Certainly the lack of testing and other exploration in this regard with the submitted patch is concerning.
In the general case the current behavior is random and not something applications can count on, and we would do well to fix it so it is less random. In particular consider the case of an application in a non-initial network namespace creating a new network namespace. It is not even possible to predict what values they will get for sysctls today.
From a backwards compatibility standpoint we are probably better off with copying from the current network namespace rather than the initial network namespace. As that more closely resembles the common case today.
Having a statement of something that is a problem today with the existing setup would probably be useful so it is clear this is not a change for the sake of change.
Eric
Le 24/02/2016 23:05, Eric W. Biederman a écrit :
[snip]
Quoted 6 lines
In the general case the current behavior is random and not something applications can count on, and we would do well to fix it so it is less random. In particular consider the case of an application in a non-initial network namespace creating a new network namespace. It is not even possible to predict what values they will get for sysctls today.
+1
Quoted 4 lines
From a backwards compatibility standpoint we are probably better off
with copying from the current network namespace rather than the initial network namespace. As that more closely resembles the common case today.
+1
_______________________________________________
Containers mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/containers
David Miller
maintainerFrom: Nicolas Dichtel <[email protected]>
Date: Thu, 25 Feb 2016 15:20:48 +0100
Quoted 10 lines · Eric W. Biederman
[snip]
Quoted 7 lines
In the general case the current behavior is random and not something applications can count on, and we would do well to fix it so it is less
random. In particular consider the case of an application in a non-initial network namespace creating a new network namespace. It is not even possible to predict what values they will get for sysctls today.+1
But there is a counter argument to this.
The admin set up the initial namespace so that any namespace instantiated by a user (even non-initial namespaces) starts with a specific set of sysctl values. So the admin "knows", he set it up intentionally this way, and it's a valid model.
This behavior is anything but random. Rather, it is very predictable and controllable.
Do you really want to find out who you're going to break out there with so many installations in the world right now?
I do not.