Re: [PATCH] ipv4: in new netns initialize sysctls in net.ipv4.conf.* with defaults

David Miller [off-list ref] writes:

From: Konstantin Khlebnikov <redacted>
Date: Sun, 21 Feb 2016 10:11:02 +0300

quoted

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 <redacted>
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.

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]

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

 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
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

From: Nicolas Dichtel <redacted>
Date: Thu, 25 Feb 2016 15:20:48 +0100

Le 24/02/2016 23:05, Eric W. Biederman a écrit :
[snip]

quoted

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.