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]

Date:   Tue, 27 Aug 2019 07:43:59 -0600
From:   David Ahern <dsahern@...il.com>
To:     Michal Kubecek <mkubecek@...e.cz>, netdev@...r.kernel.org
Cc:     Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        David Miller <davem@...emloft.net>,
        Stephen Hemminger <sthemmin@...rosoft.com>, dcbw@...hat.com,
        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 PM, Michal Kubecek wrote:
> On Mon, Aug 26, 2019 at 03:46:43PM -0600, David Ahern wrote:
>> 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?
> 
> There is only one alias so that it makes perfect sense to set it like
> any other attribute. But the series introduces a list of alternative
> names. So IMHO better analogy would be network addresses - and we do
> have RTM_NEWADDR/RTM_DELADDR for them.

RTM_*ADDR manage network layer addresses. Those are anchored to a device
but not direct attributes describing the device.

The device names are just alternative (human friendly) references to a
specific device hence they should be direct link attributes.