tree-wide: use READ_FULL_FILE_CONNECT_SOCKET at various places
Let's use the new flag wherever we read key material/passphrases/hashes
off disk, so that people can plug in their own IPC service as backend if
they like, easily.
(My main goal was actually to support this for crypttab key files — i.e.
that you can specify AF_UNIX sockets as third column in crypttab — but
that's harder to implement, since the keys are read via libcryptsetup's
API, not ours.)
Hans de Goede [Mon, 20 Jul 2020 13:06:43 +0000 (15:06 +0200)]
logind: Fix org.freedesktop.login1.set-reboot-to-boot-loader-menu saving to the wrong file in the non EFI case
According to the docs, and to the
org.freedesktop.login1.get-reboot-to-boot-loader-menu code, the
(oneshot) boot-loader-menu timeout should be stored in
/run/systemd/reboot-to-boot-loader-menu, but the set method was storing it
in /run/systemd/reboot-to-loader-menu.
This commit fixes this. Note that the fixed name also is a better match
for the dbus call names and matches the related
/run/systemd/reboot-to-boot-loader-entry structure, so fixing the set code,
rather then the get code + docs seems like the right thing to do here.
libc in the Debian container got updated to 2.31, which in combination
with clang-9 triggers systemd/systemd#14865.
This has been fixed by https://reviews.llvm.org/D74712 which is (to my
knowledge) included in clang-10. To mitigate this without upgrading to
clang-10 we can compile with -O1 which works around it as well, see
https://bugzilla.redhat.com/show_bug.cgi?id=1803203.
network: stop already running engines before updating MAC address
In NetworkdBridgeTests.test_bridge_configure_without_carrier of
systemd-networkd-tests.py
```
bridge99: MAC address: 2e:3a:ec:4d:d3:62
Assertion 'sd_ipv4ll_is_running(ll) == 0' failed at src/libsystemd-network/sd-ipv4ll.c:110, function int sd_ipv4ll_set_mac(sd_ipv4ll *, const struct ether_addr *)(). Ignoring.
bridge99: Could not update MAC address in IPv4LL client: Device or resource busy
```
vconsole-setup: downgrade log message when setting font fails on dummy console
Since commit 883eb9be985fd86d9cabe967eeeab91cdd396a81, vconsole-setup might be
called again to operate on dummy console where font operations are not
supported but where it's still important to have the correct keymap set [0][1].
vconsole-setup is mainly called by udev but can also be run via a dependency of
an early service. Both cases might end up calling vconsole-setup on the dummy
console.
The first case can happen during early boot even on systems that use (instead
of the dummy console) a "simple" video console driver supporting font
operations (such as vgacon) until a more specific driver (such as i915) takes
the console over. While this is happening vgacon is deactivated and temporarly
replaced by the dummy console [2].
There are also other cases where systemd-vconsole-setup might be called on
dummy console especially during (very) early boot. Indeed
systemd-vconsole-setup.service might be pulled in by early interactive services
such as 'dracut-cmdline-ask.service` which is run before udev.
If that happens on platforms with no grapical HWs (such as embedded ARM) or
with dummy console initially installed until a driver takes over (like Xen and
xen-fbfront) then setting font will fail.
Therefore this patch downgrades the log message emitted when setting font fails
to LOG_DEBUG and when font operations is not implemented like it's the case for
the dummy console.
When sd_netlink_call_async() timed out, then we reply the synthetic
error message, but it was not sealed. So, reading the message causes
the following assertion:
```
Assertion 'm->sealed' failed at src/libsystemd/sd-netlink/netlink-message.c:652, function netlink_message_read_internal(). Ignoring.
```
networkd: Use NLM_F_ACK on the netlink message to add a neighbor.
sd_netlink_message_set_flags is called without NLM_F_ACK which results in
a timeout while networkd is waiting for an ACK that the kernel will never send.
shared/offline-passwd: look at /usr/lib/{passwd,group} too
This changes the code to allow looking at multiple files with different
prefixes, but uses "/etc" and "/usr/lib". rpm-ostree uses
/usr/lib/{passwd,group} with nss-altfiles. I see no harm in simply trying both
paths on all systems.
A minor memory leak is fixed: hashmap_put() returns -EEXIST is the key is
present *and* and the value is different. It return 0 if the value is the
same. Thus, we would leak the user/group name if it was specified multiple
times with the same uid/gid. I opted to remove the warning message completely:
with multiple files it is reasonable to have the same name defined more than
once. But even with one file the warning is dubious: all tools that read those
files deal correctly with duplicate entries and we are not writing a linter.
Move offline-password.[ch] to shared and add test-offline-passwd
The test binary has two modes: in the default argument-less mode, it
just checks that "root" can be resolved. When invoked manually, a root
prefix and user/group names can be specified.
netlink: do not fail when new interface name is already used as an alternative name
When renaming a network interface, the new name may be used as an
alternative name. In that case, let's swap the current name and the
alternative name. That is, first drop the new name from the list of
alternative names, then rename the interface, finally set the old name
as an alternative name.
hwdb: check that uppercase digits are used in modalias patterns
This is all confusing as hell, becuase in some places lowercase hexadecimal
digits are used, and in other places uppercase. This adds a check for the
most common case that we and others got wrong.
I tried to extend the general grammar in hwdb_grammar() to include this check,
but it quickly became very complicated and didn't seem to work properly. Doing
initial parsing with more general rules is easier and also seems to give better
error messages:
/home/zbyszek/src/systemd-work/build/../hwdb.d/60-autosuspend.hwdb: 3 match groups, 5 matches, 3 properties
Pattern 'v058fp9540*' is invalid: Expected W:(0123...), found 'f' (at char 4), (line:1, col:5)
Defaulting to fedora makes it a pain to override mkosi.default
point to one of the other mkosi settings files. Instead, have
every developer manually add the symlink to his distro
of choice and don't commit the symlink to the repository by
putting it in the .gitignore.
We use LOG_PRI() in all log_*() functions, so let's do that here too for
consistency. Effectively this doesn't change anything since we only use
LOG_{INFO,DEBUG,...} as the argument.
This effectively partially reverts "rules: remove all power management from
udev" / e2452eef02a839e1928f4ffd893c93a460474ab6. The rules for emulated QEMU
hardware were removed in one fell swoop with other rules which were causing
problems. But the qemu rules were working properly (and were adjusted through
patches over time). Nowadays we have a hwdb for this, so add hwdb entries using
the new detailed modalias.
udev: change the modalias string for usb devices to include the device name
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 796b06c21b62d13c9021e2fbd9c58a5c6edb2764, 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.
udev: don't complain when udev_watch_end() is called without udev_watch_init()
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).
man: add more details for IMPORT, PROGRAM and RUN keys
967de8faceaa83c11a1215515cb135d7a8c0c32c added a note that I found very hard
to understand. Reword it, and also describe how IMPORT and PROGRAM are different
from RUN.
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.
Udev logs are full of messages about wrong operator type:
...
Reading rules file: /usr/lib/udev/rules.d/60-persistent-storage.rules
/usr/lib/udev/rules.d/60-persistent-storage.rules:30 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:30 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:30 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:30 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:30 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:30 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:54 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:57 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:60 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:63 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:66 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:67 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:93 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:107 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:110 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:113 IMPORT key takes '==' or '!=' operator, assuming '=='.
Reading rules file: /usr/lib/udev/rules.d/60-persistent-v4l.rules
/usr/lib/udev/rules.d/60-persistent-v4l.rules:7 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-v4l.rules:9 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-v4l.rules:16 IMPORT key takes '==' or '!=' operator, assuming '=='.
...
The warning was downgraded in f0beb6f816035e438d684cc52ae76fc4a44fc197, but I
think it should be removed altogether. IMPORT{program}="asdf" seems like an
obvious way to write this, and people don't expect to have to write "==".
So let's just allow any operator.
nspawn: mount os-release in two steps to make it read-only
The kernel interface requires setting up read-only bind-mounts in
two steps, the bind first and then a read-only remount.
Fix nspawn-mount, and cover this case in the integration test.
projects / thirdparty / systemd.git / log
