netdev - Re: [PATCH 1/2] net: linkwatch: send change uevent on link changes

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:   Wed, 5 Dec 2018 23:38:17 +0100
From:   Jouke Witteveen <j.witteveen@...il.com>
To:     davem@...emloft.net
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] net: linkwatch: send change uevent on link changes

On Wed, Dec 5, 2018 at 8:45 PM David Miller <davem@...emloft.net> wrote:
>
> From: Jouke Witteveen <j.witteveen@...il.com>
> Date: Wed, 5 Dec 2018 14:50:31 +0100
>
> > For example, I maintain a network manager that delegates the actual
> > networking work to specialized programs.
>
> Basically "I've implemented things using separate programs"

I was trying to give an example of a typical system administrator task.

> > Basically, it is an implementation of network manager logic in shell
> > script. For such a shell script, it is easy to respond to uevents
> > (via udev, or alternatives), but responding to rtnetlink messages
> > would require a separate program.
>
> And "In order to use rtnetlink I'll need a separate program!"
>
> (╯°□°）╯︵ ┻━┻
>
> So it's ok to use the separate program paradigm for dividing up
> the tasks, but not for processing events?
>
> I'm not convinced.

This is about automation. When you want to take some action in
response to an event, you want the event system to be accommodating.
In that sense, it is indeed more ok for actions to require separate
programs than for event listening.

> Either use the facility we have or extend it to fill a valid missing
> need.
>
> I'm not applying these patches, your logic doesn't add up and it's
> inconsistent with our clear goals of not duplicating functionality.

Can you elaborate a bit? I may not be aware of the policy you have in
mind. Furthermore, I fail to see how these "change" events in response
to link state changes are not to be expected. To me, it looks like
uevents are there precisely to inform userspace about this kind of
changes.
As I asked in my conceptual argument, please consider this patch an
extension of uevent coverage, more than an attack on rtnetlink (which
it is definitely not).

Regards,
- Jouke