This fixes a race where a block device that pops up and immediately is
locked (such as a loopback device in preparation) might result in
udev never run any rules for it, and thus never turn on inotify watching
for it (as inotify watching is controlled via an option set via udev
rules), thus not noticing when the device is unlocked/closed again
(which is noticed via IN_CLOSE_WRITE inotify events).
This changes two things:
1. Whenever we encounter a locked block device we'll now inotify watch
it, so that it is guaranteed we'll notice when the BSD lock fd is
closed again, and will reprobe.
2. We'll now turn off inotify watching again once we realise the
udev rules don't actually want that. Previously, once watching a
device was enabled via a udev rule, it would be watched forever until
the device disappeared, even if the option was dropped by the rules
for later events.
Together this will make sure that we'll watch the device via inotify
in both of the following cases:
a) The block device has been BSD locked when udev wanted to look at it
b) The udev rules run for the last seen event for the device say so
In all other cases inotify is off for block devices.
This new behaviour both fixes the race, but also makes the most sense,
as the rules (when they are run) actually really control the watch state
now. And if someone BSD locks a block device then it should be OK to
inotify watch it briefly until the lock is released again as the user
this way more or less opts into the locking protocol.
This effectively reverts commit 67acde4869.
After commits 569ad251ad and
67acde4869, -EACCES errors are ignored,
and thus 'udevadm trigger' succeeds even when it is invoked by non-root
users. Moreover, on -EACCES error, log messages are shown in debug
level, so usually we see no message, and users are easily confused
why uevents for devices are not triggered.
Let's open the device node to modify with O_PATH, and then adjust it
only after verifying everything is in order. This fixes a race where the
a device appears, disappears and quickly reappers, while we are still
running the rules for the first appearance: when going by path we'd
possibly adjust half of the old and half of the new node. By O_PATH we
can pin the node while we operate on it, thus removing the race.
Previously, we'd do a superficial racey check if the device node changed
undearneath us, and would propagate EEXIST in that case, failing the
rule set. With this change we'll instead gracefully handle this, exactly
like in the pre-existing case when the device node disappeared in the
meantime.
If the whole call is simple and we don't need to look at the return value
apart from the conditional, let's use a form without assignment of the return
value. When the function call is more complicated, it still makes sense to
use a temporary variable.
Graphics tablet devices comprise multiple event nodes, usually a Pen, Finger
and Pad node (that's how the kernel postfixes them). Pen and Pad are labeled
as ID_INPUT_TABLET but the pad doesn't actually send stylus events - it
doesn't usually have BTN_TOOL_PEN, merely BTN_STYLUS.
For the last several years, libwacom has set ID_INPUT_TABLET_PAD for all pad
devices known to it based on vid/pid and a "* Pad" name match. That does not
cover devices not in libwacom. libinput relies on ID_INPUT_TABLET_PAD to
initialize the pad backend.
We can't drop ID_INPUT_TABLET without breaking userspace, but we can add
ID_INPUT_TABLET_PAD ourselves - where a device has BTN_0 in addition to
BTN_STYLUS, let's add it as a pad.
There are some devices (notably: bamboos) that use BTN_LEFT instead of BTN_0
but they are relatively rare and there's a risk of mislabeling those devices,
so let's just stick with BTN_0 only.
Behaviour is not identical, as shown by the tests in test-strv.
The combination of EXTRACT_UNQUOTE without EXTRACT_RELAX only appears in
the test, so it doesn't seem particularly important. OTOH, the difference
in handling of squished parameters could make a difference. New behaviour
is what both bash and python do, so I think we can ignore this corner case.
This change has the following advantages:
- the duplication of code paths that do a very similar thing is removed
- extract_one_word() / strv_split_extract() return a proper error code.
This tries to address the "bind"/"unbind" uevent kernel API breakage, by
changing the semantics of device tags.
Previously, tags would be applied on uevents (and the database entries
they result in) only depending on the immediate context. This means that
if one uevent causes the tag to be set and the next to be unset, this
would immediately effect what apps would see and the database entries
would contain each time. This is problematic however, as tags are a
filtering concept, and if tags vanish then clients won't hence notice
when a device stops being relevant to them since not only the tags
disappear but immediately also the uevents for it are filtered including
the one necessary for the app to notice that the device lost its tag and
hence relevance.
With this change tags become "sticky". If a tag is applied is once
applied to a device it will stay in place forever, until the device is
removed. Tags can never be removed again. This means that an app
watching a specific set of devices by filtering for a tag is guaranteed
to not only see the events where the tag is set but also all follow-up
events where the tags might be removed again.
This change of behaviour is unfortunate, but is required due to the
kernel introducing new "bind" and "unbind" uevents that generally have
the effect that tags and properties disappear and apps hence don't
notice when a device looses relevance to it. "bind"/"unbind" events were
introduced in kernel 4.12, and are now used in more and more subsystems.
The introduction broke userspace widely, and this commit is an attempt
to provide a way for apps to deal with it.
While tags are now "sticky" a new automatic device property
CURRENT_TAGS is introduced (matching the existing TAGS property) that
always reflects the precise set of tags applied on the most recent
events. Thus, when subscribing to devices through tags, all devices that
ever had the tag put on them will be be seen, and by CURRENT_TAGS it may
be checked whether the device right at the moment matches the tag
requirements.
See: #7587#7018#8221
The parent process may not perform any label operation, so the
database might not get updated on a SELinux policy change on its own.
Reload the label database once on a policy change, instead of n times
in every started child.
Similarly to "setup" vs. "set up", "fallback" is a noun, and "fall back"
is the verb. (This is pretty clear when we construct a sentence in the
present continous: "we are falling back" not "we are fallbacking").
Fixed below systemd codesonar warning.
isprint() is invoked here with an argument of signed
type char, but only has defined behavior for int arguments that are
either representable as unsigned char or equal to the value
of macro EOF(-1).
As per codesonar report, in a number of libc implementations, isprint()
function implemented using lookup tables (arrays): passing in a
negative value can result in a read underrun.
When the kernel does not provide a modalias, we generate our own for usb devices.
For some reason, we generated the expected usb:vXXXXpYYYY string, suffixed by "*".
It was added that way already in 796b06c21b, but I
think that was a mistake, and Kay was thinking about the match pattern instead
of the matched string.
For example, for a qemu device:
old: "usb:v0627p0001*"
new: "usb:v0627p0001:QEMU USB Tablet"
On the match side, all hwdb files in the wild seem to be using match patterns
with "*" at the end. So we can add more stuff to our generated modalias with
impunity.
This will allow more obvious and more certain matches on USB devices. In
principle the vendor+product id should be unique, but it's only 8 digits, and
there's a high chance of people getting this wrong. And matching the wrong
device would be quite problematic. By including the name in the match string we
make a mismatch much less likely.
E.g. udevadm test prints "Invalid inotify descriptor." which is
meaningless without any context. I think it should be OK to call udev_watch_end()
from a cleanup path without any warning (even at debug level).
There is no reason to consider this wrong. In fact one could argue that +=
is more appropriate, because we always add to options, and not replace previous
assignments. If we output a debug message, we implicitly ask people to "fix" this,
and we shouldn't.
Also, all our rules use += right now.
Let's add a catalog entry explaining further details.
Most importantly though: talk to PID 1 directly, via the private D-Bus
socket, so that this actually works correctly during early boot, where
D-Bus is not around.
All devices behind a SPI controller have the same udev ID_PATH property.
This is a problem for predicable network names for CAN controllers.
CAN controllers, in contrast to Ethernet controllers, don't have a MAC
Address, so there's no way to tell two CAN controllers on the same SPI
host controller apart:
$ udevadm info /sys/class/net/can0
P: /devices/platform/soc/fe204000.spi/spi_master/spi0/spi0.1/net/can0
L: 0
E: DEVPATH=/devices/platform/soc/fe204000.spi/spi_master/spi0/spi0.1/net/can0
E: INTERFACE=can0
E: IFINDEX=3
E: SUBSYSTEM=net
E: USEC_INITIALIZED=11187199
E: ID_PATH=platform-fe204000.spi
E: ID_PATH_TAG=platform-fe204000_spi
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/can0
E: TAGS=:systemd:
$ udevadm info /sys/class/net/can1
P: /devices/platform/soc/fe204000.spi/spi_master/spi0/spi0.0/net/can1
L: 0
E: DEVPATH=/devices/platform/soc/fe204000.spi/spi_master/spi0/spi0.0/net/can1
E: INTERFACE=can1
E: IFINDEX=4
E: SUBSYSTEM=net
E: USEC_INITIALIZED=11192211
E: ID_PATH=platform-fe204000.spi
E: ID_PATH_TAG=platform-fe204000_spi
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/can1
E: TAGS=:systemd:
With this the chip select number is added to the ID_PATH, to make
predictable network names possible.
$ sudo udevadm info /sys/class/net/can0
P: /devices/platform/soc/fe204000.spi/spi_master/spi0/spi0.1/net/can0
L: 0
E: DEVPATH=/devices/platform/soc/fe204000.spi/spi_master/spi0/spi0.1/net/can0
E: INTERFACE=can0
E: IFINDEX=3
E: SUBSYSTEM=net
E: USEC_INITIALIZED=11187199
E: ID_PATH=platform-fe204000.spi-cs-1
E: ID_PATH_TAG=platform-fe204000_spi-cs-1
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/can0
E: TAGS=:systemd:
$ sudo udevadm info /sys/class/net/can1
P: /devices/platform/soc/fe204000.spi/spi_master/spi0/spi0.0/net/can1
L: 0
E: DEVPATH=/devices/platform/soc/fe204000.spi/spi_master/spi0/spi0.0/net/can1
E: INTERFACE=can1
E: IFINDEX=4
E: SUBSYSTEM=net
E: USEC_INITIALIZED=11192211
E: ID_PATH=platform-fe204000.spi-cs-0
E: ID_PATH_TAG=platform-fe204000_spi-cs-0
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/can1
E: TAGS=:systemd:
