I think the second paragraph of the following entry in NEWS needs to be removed or updated.

    * Various systemd services have been hardened with
      ProtectKernelTunables=yes, ProtectControlGroups=yes,
      RestrictAddressFamilies=.

      In particular, systemd-udevd.service is now run in a Seccomp-based
      sandbox that prohibits access to AF_INET and AF_INET6 sockets and
      thus access to the network. This might break code that runs from udev
      rules that tries to talk to the network. Doing that is generally a
      bad idea and unsafe due to a variety of reasons. It's also racy as
      device management would race against network configuration. It is
      recommended to rework such rules to use the SYSTEMD_WANTS property on
      the relevant devices to pull in a proper systemd service (which can
      be sandboxed differently and ordered correctly after the network
      having come up). If that's not possible consider reverting this
      sandboxing feature locally by removing the RestrictAddressFamilies=
      setting from the systemd-udevd.service unit file, or adding AF_INET
      and AF_INET6 to it.

I'm reading http://git.kernel.org/cgit/network/ethtool/ethtool.git/tree/NEWS

• Feature: Use netlink socket when AF_INET not available

http://git.kernel.org/cgit/network/ethtool/ethtool.git/tree/ethtool.c?id=9674a827b9baf1503a69dd91b7981a163bd45e77#n4769

                /* Open control socket. */
                ctx.fd = socket(AF_INET, SOCK_DGRAM, 0);
                if (ctx.fd < 0)
                        ctx.fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_GENERIC);
                if (ctx.fd < 0) {
                        perror("Cannot get control socket");
                        return 70;
                }

Shouldn't we do the same?

Shouldn't we do the same?

Well, this is a new feature: torvalds/linux@025c68186e07
So, this doesn't fix #4293 on older kernels.

So, we allow AF_INET. Why not to allow AF_INET6 too?

So, we allow AF_INET. Why not to allow AF_INET6 too?

Yupp, I figure you are right: if we block AF_INET we should also block AF_INET6, and if we do not block either, we should not block the other either. They should always come in a pair I guess.

@yuwata can you rework the patch to also unblock AF_INET6 hence? Also, please drop the NEWS blurb that's out-of-date now from the file, in the same commit.

I think we should probably also implement the logic @evverx suggested (i.e. falling back to AF_NETLINK if AF_INET is not available for the interface ioctls everywhere). Even if it only works on new kernels for now I think it's in the long run the better choice. However, this change can be done later, as it doesn't fix anything...

Force pushed updated version. Thank you.