netdev - Re: [PATCH net-next] net: ipv4: allocate ipv4_devconf memory for init

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMDZJNXwNeLh_24UOHctGNzwQsrA15CH=egh_Qj21EinjWDZzQ@mail.gmail.com>
Date:   Mon, 17 Dec 2018 17:55:04 +0800
From:   Tonghao Zhang <xiangxia.m.yue@...il.com>
To:     Cong Wang <xiyou.wangcong@...il.com>,
        David Miller <davem@...emloft.net>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] net: ipv4: allocate ipv4_devconf memory for init_net

On Mon, Dec 17, 2018 at 3:06 AM Cong Wang <xiyou.wangcong@...il.com> wrote:
>
> On Sun, Dec 16, 2018 at 8:24 AM <xiangxia.m.yue@...il.com> wrote:
> >
> > From: Tonghao Zhang <xiangxia.m.yue@...il.com>
> >
> > The devconf setting on the init_net will affect other
> > namespace when them created. For example:
> >
> > $ cat /proc/sys/net/ipv4/conf/all/rp_filter
> > 0
> > $ echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter
> > $ cat /proc/sys/net/ipv4/conf/all/rp_filter
> > 2
> >
> > $ ip netns add ns100
> > $ ip netns exec ns100 bash
> > $ cat /proc/sys/net/ipv4/conf/all/rp_filter
> > 2
> >
> > The value of rp_filter in the ns100, should be 0 as
> > default, but it is 2 same as _init_net_.
>
> This has been a known issue for a long time. There
> were several attempts to fix this.
>
> The concern here is whether it breaks existing applications'
> expectation with the change like yours. There was a proposal
> introduces a new /proc file to control this behavior, I forget
> why it is not accepted either. Please check netdev archives.
I check netdev archives and a patch to fix it, but I do not find why
not applied.

https://lore.kernel.org/patchwork/patch/493547/
> Thanks.