netdev - Re: [PATCH net-next] net: do not create fallback tunnels for non-default namespaces

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: <CANn89i+9w=2U_kkJc+UBZ5CDz=bszp43Guv4+=2f634pXFG9vg@mail.gmail.com>
Date:   Fri, 9 Mar 2018 04:53:07 -0800
From:   Eric Dumazet <edumazet@...gle.com>
To:     Jiri Benc <jbenc@...hat.com>
Cc:     "David S . Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH net-next] net: do not create fallback tunnels for
 non-default namespaces

Hi Jiri

On Fri, Mar 9, 2018 at 3:06 AM, Jiri Benc <jbenc@...hat.com> wrote:
> On Thu,  8 Mar 2018 12:51:41 -0800, Eric Dumazet wrote:
>> Note that these tunnels are still created for the initial namespace,
>> to be the least intrusive for typical setups.
>
> Since this is a knob and must be turned on explicitly, why we don't get
> rid of the automatic interfaces even for the initial name space? It
> causes only problems nowadays, such as
>
> ip link add name gre0 type gre <tunnel_options...>
>
> failing with "File exists" even if there was no gre0 interface before.
> And of course, even with the error, the interface with the name "gre0"
> appears in the system. And of course, it does not have any of the
> options specified. This is highly confusing. Not to mention the
> autocreated gre0 interface is basically useless.

Unless you bring it up ;)

>
> I'd like to switch the knob on by default on my systems and have the
> kernel behave sane, finally, even without name spaces.

Compatibility problems,  mostly.
Some users might depend on existing behavior.

You and me would not care of breaking our setups, but maybe not
unaware people out there.

Since init_ns is created at boot time before the sysctl can be
changed, we rather should not change the default behavior for init_ns.

Thanks.