Previous commit makes drop ID_NET_DRIVER=, ID_NET_LINK_FILE=, and
ID_NET_NAME= properties for network interfaces on 'move' uevent.
ID_NET_DRIVER= and ID_NET_LINK_FILE= properties are used by networkctl.
ID_NET_NAME= may be used by end-user rules or programs. So, let's
re-assign them on 'move' uevent. (Note that strictly speaking, this
makes them re-assigned on all but 'remove' uevent.)
To make Driver= in [Match] section work in containers.
Note that ID_NET_DRIVER= property in udev database is set with the
result of the ethtool. So, this should not change anything for
non-container cases.
Closes#15678.
This is a follow-up for 9f83091e3c.
Instead of reading the mtime off the configuration files after reading,
let's do so before reading, but with the fd we read the data from. This
is not only cleaner (as it allows us to save one stat()), but also has
the benefit that we'll detect changes that happen while we read the
files.
This also reworks unit file drop-ins to use the common code for
determining drop-in mtime, instead of reading system clock for that.
This is a security feature, and we thus shouldn't derive the random MACs
from a potentially guessable source. MAC addresses are after all facing
to the outside, and can be interacted with from untrusted environments.
Hence, let's generate them the same way as we generate UUIDs: from
getrandom() or /dev/urandom, and optionally with RDRAND if that's
supported.
RDRAND should be fine, since this is not cryptographic key material, but
ultimately public information. We just want to make sure conflicts are
not likely.
Previously we'd generate the MACs via rand(), which means given the
short seed they are a little bit too guessable, making collisions too
likely. See #14355 in particular.
Fixes: #14355
(Note that #14355 was already fixed by
a0f11d1d11, but I think we should do
better even, and not rely on rand() and uninitialized random pools)
When setting flow control attributes of an interface we first acquire
the current settings and then add in the new settings before applying
them again. This only works on interfaces that implement the ethtool
ioctls. on others we'll see an ugly "Could not set flow control of"
message, simply because we issue the SIOCETHTOOL ioctl once, for getting
the data. In particular we'll get it for the "lo" interface all the
time, which sucks hard. Let's get rid of it.
Prompted by the discussions in #15180.
This is a bit more complex than I hoped, since for PID 1 we need to pass
in the synethetic environment block in we generate on demand.
The function sd_device_get_property_value has some paths where it exits without
touching the n pointer. In those cases, n remained uninitialized until it was
eventually read inside isempty where it caused the segmentation fault.
Fixes#15078
Two releases ago we started warning about this, and I think it is now to turn
this into a hard error. People get bitten by this every once in a while, and
there doesn't see to be any legitimate use case where the same .link or
.network files should be applied to _all_ interfaces, since in particular that
configuration would apply both to lo and any other interfaces. And if for
whatever reason that is actually desired, OriginalName=* or Name=* can be
easily added to silence the warning and achieve the effect.
(The case described in #12098 is particularly nasty: 'echo -n >foo.network'
creates a mask file, 'echo >foo.network' creates a "match all" file.)
Fixes#717, #12098 for realz now.
Yu Watanabe