In a container with a non-trivial user namespace, we cannot rely on
libudev communicating with udevd as a way to monitor device nodes,
for the following reasons:
* If uid 0 from the host is not mapped to uid 0 in the container, libudev
cannot authenticate netlink messages from the host, because their sender
uid appears to be the overflowuid. Resolving this by mapping uid 0 into
the container is not allowed when creating user namespaces as an
unprivileged user, and even when running as a privileged user, it might
be desirable for the real uid 0 to not be mapped as a way to harden the
security boundary between container and host.
* Depending on the container configuration, initial enumeration might
not be able to read /run/udev from the host system. If it can't, sysfs
attributes will still work because those are read directly from the
kernel via sysfs, but udev properties coming from user-space rules
(in particular ID_INPUT_JOYSTICK and friends) will appear to be missing.
* The protocols between udevd and libudev (netlink messages for monitoring,
and /run/udev for initial enumeration) are considered to be private to
a particular version of udev, and are not a stable API; but in a
container, we cannot expect that our copy of libudev is at exactly the
same version as udevd on the host system.
Sidestep this by adding a code path that continues to use libudev for
the parts that work regardless of whether udevd is running or can be
communicated with.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
ab3416c61f