From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758549AbcBXWOt (ORCPT ); Wed, 24 Feb 2016 17:14:49 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:52752 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752802AbcBXWOs (ORCPT ); Wed, 24 Feb 2016 17:14:48 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: David Miller Cc: khlebnikov@yandex-team.ru, netdev@vger.kernel.org, containers@lists.linux-foundation.org, vvs@virtuozzo.com, linux-kernel@vger.kernel.org References: <20160221071102.9686.63148.stgit@buzz> <20160223.182121.2101846699151527296.davem@davemloft.net> Date: Wed, 24 Feb 2016 16:05:10 -0600 In-Reply-To: <20160223.182121.2101846699151527296.davem@davemloft.net> (David Miller's message of "Tue, 23 Feb 2016 18:21:21 -0500 (EST)") Message-ID: <87y4a9ix2h.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX18O23HqN1lFopR5mI6L82kuEiOxigtf2WU= X-SA-Exim-Connect-IP: 67.3.228.143 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4639] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] * 0.2 T_XMDrugObfuBody_14 obfuscated drug references X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;David Miller X-Spam-Relay-Country: X-Spam-Timing: total 1683 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.2 (0.2%), b_tie_ro: 2.3 (0.1%), parse: 0.99 (0.1%), extract_message_metadata: 23 (1.3%), get_uri_detail_list: 2.7 (0.2%), tests_pri_-1000: 8 (0.5%), tests_pri_-950: 1.69 (0.1%), tests_pri_-900: 1.38 (0.1%), tests_pri_-400: 27 (1.6%), check_bayes: 26 (1.5%), b_tokenize: 9 (0.6%), b_tok_get_all: 8 (0.5%), b_comp_prob: 3.3 (0.2%), b_tok_touch_all: 2.4 (0.1%), b_finish: 0.63 (0.0%), tests_pri_0: 211 (12.5%), check_dkim_signature: 0.49 (0.0%), check_dkim_adsp: 3.2 (0.2%), tests_pri_500: 1402 (83.3%), poll_dns_idle: 1395 (82.9%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] ipv4: in new netns initialize sysctls in net.ipv4.conf.* with defaults X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org David Miller writes: > From: Konstantin Khlebnikov > Date: Sun, 21 Feb 2016 10:11:02 +0300 > >> 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 >> 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