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]

Message-ID: <CAJ2ouazSL_NR5BJU0NJyDtcb5q9BLqwH8g0LpV9Ze+C6NqM_TQ@mail.gmail.com>
Date:   Wed, 5 Dec 2018 14:50:31 +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 5:50 AM David Miller <davem@...emloft.net> wrote:
>
> From: Jouke Witteveen <j.witteveen@...il.com>
> Date: Sat, 1 Dec 2018 17:00:21 +0100
>
> > Make it easy for userspace to respond to acquisition/loss of carrier.
> > The uevent is picked up by udev and, on systems with systemd, the
> > device unit of the interface announces a configuration reload.
> >
> > Signed-off-by: Jouke Witteveen <j.witteveen@...il.com>
> > ---
> > I did not want to change the commit message into a systemd-howto, but
> > subscribing to udev events can be done through a line like
> >     ReloadPropagatedFrom=sys-subsystem-net-devices-%i.device
> > in a systemd unit file.
>
> I want to hear more about "why".

Let me give a conceptual and a practical reason.

Conceptual.
>From the net-subsystem point of view, it may not be clear why we
should add uevents. However, from the uevent point of view, it is odd
that networking devices do not send out "change" events when their
medium (=link) state changes. For consistency, it would be better to
also send out uevents. I would go as far as to say that uevents should
have been used from the start, but they were not yet available back
then (I believe rtnetlink predates uevents by at least five years).
A good summary of this argument in favor of the patch is given by
Stephen Hemminger: it makes sense.

> If we have the rtnetlink message that can be listened for, userspace
> ought to use that.  That's what it is there for.

Practical.
If userspace refers to programs with fewer privileges than the kernel,
than, indeed, it is not hard to set up a listener for rtnetlink
messages in C. However, if it refers to system administration, then
uevents are far more convenient to listen to, since they are
propagated by udev and its likes.
For example, I maintain a network manager that delegates the actual
networking work to specialized programs. 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.

The way I see it is that rtnetlink and uevents represent two different
views of the system and link state changes should be visible in both.

Regards,
- Jouke