netdev - Re: [PATCH] ip link: Prevent duplication of table id for vrf tables

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: <CAK989ycxqKU0wYZdfNsMKVOtS_ENg+jhuYu5np7Hd-NdKLo4AQ@mail.gmail.com>
Date:   Mon, 9 Mar 2020 08:16:49 -0400
From:   Donald Sharp <sharpd@...ulusnetworks.com>
To:     David Ahern <dsahern@...il.com>
Cc:     netdev@...r.kernel.org, dsahern@...nel.org,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        Stephen Worley <sworley@...ulusnetworks.com>
Subject: Re: [PATCH] ip link: Prevent duplication of table id for vrf tables

David -

I'm more than a bit confused about this stance.  I've been repeatedly
told by the likes of you, Roopa, and Nikolay that we cannot modify the
kernel behavior.  I get that, so that leaves me with user space
responses.  I went this route because not allowing the end user to
make this mistake would have saved us a stupid amount of time from
having to debug/understand/rectify ( rinse repeat for every incident
).  A warning wouldn't have saved us here since this was all automated
and a warning won't generate any actionable return codes from using
`ip link add...`.  If the argument is that other people are doing it
wrong too, point me at them and I'll submit patches there too.  In
other words a user management problem that the kernel/iproute2 hog
ties me from being actually able to stop mistakes when they happen is
an interesting response.

Part of this is that the routing stack considers vrf completely
independent and we don't have duplicate labels to identify the same
table( nor can I think of a good use case where this would be even
advisable and if you can please let me know as that I want to
understand this ).  We have a set of actions we perform when we
receive routing data from the kernel and if we don't act on the right
vrf we've broken routing.  This routing data sent over the netlink bus
is the tableid, if we can't stop users from making mistakes, can we
modify the netlink code actually send us disambiguous data then and
include the label as well as part of the route update?

thanks!

donald

On Sun, Mar 8, 2020 at 10:22 PM David Ahern <dsahern@...il.com> wrote:
>
> On 3/7/20 1:59 PM, Donald Sharp wrote:
> > Creation of different vrf's with duplicate table id's creates
> > a situation where two different routing entities believe
> > they have exclusive access to a particular table.  This
> > leads to situations where different routing processes
> > clash for control of a route due to inadvertent table
> > id overlap.  Prevent end user from making this mistake
> > on accident.
>
> I get the pain, but it is a user management problem and ip is but one
> tool. I think at most ip warns the user about the table duplication; it
> can't fail the create.