netdev - Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames

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: <5d79fba4-f82e-97a7-7846-fd1de089a95b@gmail.com>
Date:   Mon, 26 Aug 2019 15:46:43 -0600
From:   David Ahern <dsahern@...il.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Jiri Pirko <jiri@...nulli.us>
Cc:     Roopa Prabhu <roopa@...ulusnetworks.com>,
        netdev <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Stephen Hemminger <sthemmin@...rosoft.com>, dcbw@...hat.com,
        Michal Kubecek <mkubecek@...e.cz>,
        Andrew Lunn <andrew@...n.ch>, parav@...lanox.com,
        Saeed Mahameed <saeedm@...lanox.com>,
        mlxsw <mlxsw@...lanox.com>
Subject: Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and
 delete alternative ifnames

On 8/26/19 10:55 AM, Jakub Kicinski wrote:
> On Mon, 26 Aug 2019 18:09:16 +0200, Jiri Pirko wrote:
>> DaveA, Roopa. Do you insist on doing add/remove of altnames in the
>> existing setlist command using embedded message op attrs? I'm asking
>> because after some time thinking about it, it still feels wrong to me :/
>>
>> If this would be a generic netlink api, we would just add another couple
>> of commands. What is so different we can't add commands here?
>> It is also much simpler code. Easy error handling, no need for
>> rollback, no possibly inconsistent state, etc.
> 
> +1 the separate op feels like a better uapi to me as well.
> 
> Perhaps we could redo the iproute2 command line interface to make the
> name the primary object? Would that address your concern Dave and Roopa?
> 

No, my point is exactly that a name is not a primary object. A name is
an attribute of a link - something that exists for the convenience of
userspace only. (Like the 'protocol' for routes, rules and neighbors.)

Currently, names are changed by RTM_NEWLINK/RTM_SETLINK. Aliases are
added and deleted by RTM_NEWLINK/RTM_SETLINK. Why is an alternative name
so special that it should have its own API?

If only 1 alt name was allowed, then RTM_NEWLINK/RTM_SETLINK would
suffice. Management of it would have the same semantics as an alias -
empty string means delete, non-empty string sets the value.

So really the push for new RTM commands is to handle an unlimited number
of alt names with the ability to change / delete any one of them. Has
the need for multiple alternate ifnames been fully established? (I don't
recall other than a discussion about parallels to block devices.)