This API is a complete mess. We forgot to do a hashed comparison for duplicate
entries and we use a direct pointer comparison. For trivial_hash_ops the result
is the same. For all other case, it's not. Fixing this properly will require
auditing all the uses of set_put() and ordered_set_put(). For now, let's just
acknowledge the breakage.
We would add and remove definitions based on which colors were used by other
code. Let's just define all of them to simplify tests and allow easy comparisons
which colors look good.
There are a lot of edge cases that the current implementation
doesn't handle, especially in cases where one of passwd/shadow
exists and the other doesn't exist. For example, if
--root-password is specified, we will write /etc/shadow but
won't add a root entry to /etc/passwd if there is none.
To fix some of these issues, we constrain systemd-firstboot to
only modify /etc/passwd and /etc/shadow if both do not exist
already (or --force) is specified. On top of that, we calculate
all necessary information for both passwd and shadow upfront so
we can take it all into account when writing the actual files.
If no root password options are given --force is specified or both
files do not exist, we lock the root account for security purposes.
Fixes#16401.
c80a9a33d0 introduced the .can_fail field,
but didn't set it on .targets. Targets can fail through dependencies.
This leaves .slice and .device units as the types that cannot fail.
$ systemctl cat bad.service bad.target bad-fallback.service
[Service]
Type=oneshot
ExecStart=false
[Unit]
OnFailure=bad-fallback.service
[Service]
Type=oneshot
ExecStart=echo Fixing everythign!
$ sudo systemctl start bad.target
systemd[1]: Starting bad.service...
systemd[1]: bad.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: bad.service: Failed with result 'exit-code'.
systemd[1]: Failed to start bad.service.
systemd[1]: Dependency failed for bad.target.
systemd[1]: bad.target: Job bad.target/start failed with result 'dependency'.
systemd[1]: bad.target: Triggering OnFailure= dependencies.
systemd[1]: Starting bad-fallback.service...
echo[46901]: Fixing everythign!
systemd[1]: bad-fallback.service: Succeeded.
systemd[1]: Finished bad-fallback.service.
The Address objects in the set generated by ndisc_router_generate_addresses()
have the equivalent prefixlen, flags, prefered lifetime.
This commit makes ndisc_router_generate_addresses() return Set of
in6_addr.
The CI occasionally fail in test-path with a timeout. test-path loads
units from the filesystem, and this conceivably might take more than
the default limit of 3 s. Increase the timeout substantially to see if
this helps.
Opening a verity device is an expensive operation. The kernelspace operations
are mostly sequential with a global lock held regardless of which device
is being opened. In userspace jumps in and out of multiple libraries are
required. When signatures are used, there's the additional cryptographic
checks.
We know when two devices are identical: they have the same root hash.
If libcrypsetup returns EEXIST, double check that the hashes are really
the same, and that either both or none have a signature, and if everything
matches simply remount the already open device. The kernel will do
reference counting for us.
In order to quickly and reliably discover if a device is already open,
change the node naming scheme from '/dev/mapper/major:minor-verity' to
'/dev/mapper/$roothash-verity'.
Unfortunately libdevmapper is not 100% reliable, so in some case it
will say that the device already exists and it is active, but in
reality it is not usable. Fallback to an individually-activated
unique device name in those cases for robustness.
../src/home/homectl-pkcs11.c:19:13: warning: ‘pkcs11_callback_data_release’ defined but not used [-Wunused-function]
19 | static void pkcs11_callback_data_release(struct pkcs11_callback_data *data) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
decompress_blob_zstd() would allocate ever bigger buffers in a loop trying to
get a buffer big enough to decompress the input data. This is wasteful, since
we can just query the size of the decompressed data from the compressed header.
Worse, it doesn't work when the output size is capped, i.e. when dst_max != 0.
If the decompressed blob happened to be bigger than dst_max, decompression
would fail with -ENOBUFS. We need to use "stream decompression" instead, and
only get min(uncompressed size, dst_max) bytes of output.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1856037 in a second way.
SD_JOURNAL_FOREACH_DATA() and SD_JOURNAL_FOREACH_UNIQUE() would immediately
terminate when a field couldn't be accessed. This can happen for example when a
field is compressed with an unavailable compression format. But it's likely
that this is the wrong thing to do: the caller for example might want to
iterate over the fields but isn't interested in all of them. coredumpctl is
like this: it uses SD_JOURNAL_FOREACH_DATA() but only uses a subset of the
fields.
Add two new functions sd_journal_enumerate_good_data() and
sd_journal_enumerate_good_unique() that retry sd_journal_enumerate_data() and
sd_journal_enumerate_unique() if the return value is something that applies to
a single field: ENOBUS, E2BIG, EOPNOTSUPP.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1856037.
An alternative would be to make the macros themselves smarter instead of adding
new symbols, and do the looping internally in the macro. I don't like that
approach for two reasons. First, it would embed the logic in the macro, so
recompilation would be required if we decide to update the logic. With the
current version of the patch, recompilation is required to use the new symbols,
but after that, library upgrades are enough. So the current approach is safer
in case further updates are needed. Second, our headers use primitive C, and it
is hard to do the macros without using newer features.
Let's split this out into its own helper function we can reuse at
various places.
Also, let's avoid signed values where we can so that we can cover more
of the available time range.
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.)
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.
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
```
Since commit 883eb9be98, 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.
Fixes: #16406.
[0] https://github.com/systemd/systemd/issues/10826
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1652473
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/vga/vgaarb.c?h=v5.7#n204
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.
```
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.
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.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1857530.
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.
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.
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.
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.
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.
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.
Fixes#16484
If DHCP4 client lost a lease, and then soon acquire new lease, then
the removal of the old address may not be completed. If that happens,
and the new and old addresses are the same, then the new address will be
considered as a foreign address. Such a situation can occur when the
DHCP4 server is restarted.
This makes networkd wait for the removal of the old address when a new
lease is acquired.
This also makes the link in configuring state when renewing address.
When DHCP6 and RA are enabled, and RA does not provide any addresses,
then link may become configured state even if no address is assigned,
due to the time-lag between RA completion and DHCP reply.
This makes if DHCP is explicitly enabled, then link must have at least
one valid address to be in the configured state.
let's separate things out a bit, to make it easier to discern log output
and catalog data.
catalog data is now colored green (which is a color we don't use for log
data currently), and prefixed with a block shade.
When the RTC time at boot is off in the future by a few days, OnCalendar=
timers will be scheduled based on the time at boot. But if the time has been
adjusted since boot, the timers will end up scheduled way in the future, which
may cause them not to fire as shortly or often as expected.
Update the logic so that the time will be adjusted based on monotonic time.
We do that by calculating the adjusted manager startup realtime from the
monotonic time stored at that time, by comparing that time with the realtime
and monotonic time of the current time.
Added a test case to validate this works as expected. The test case creates a
QEMU virtual machine with the clock 3 days in the future. Then we adjust the
clock back 3 days, and test creating a timer with an OnCalendar= for every 15
minutes. We also check the manager startup timestamp from both `systemd-analyze
dump` and from D-Bus.
Test output without the corresponding code changes that fix the issue:
Timer elapse outside of the expected 20 minute window.
next_elapsed=1594686119
now=1594426921
time_delta=259198
With the code changes in, the test passes as expected.
The test is failing in koji, and the line from printf() does not end up
in the logs for some reason. log_info() works fine, so let's just use
that here too.
Read-only /var/tmp is more likely, because it's backed by a real device. /tmp
is (by default) backed by tmpfs, but it doesn't have to be. In both cases the
same consideration applies.
If we boot with read-only /var/tmp, any unit with PrivateTmp=yes would fail
because we cannot create the subdir under /var/tmp to mount the private directory.
But many services actually don't require /var/tmp (either because they only use
it occasionally, or because they only use /tmp, or even because they don't use the
temporary directories at all, and PrivateTmp=yes is used to isolate them from
the rest of the system).
To handle both cases let's create a read-only directory under /run/systemd and
mount it as the private /tmp or /var/tmp. (Read-only to not fool the service into
dumping too much data in /run.)
$ sudo systemd-run -t -p PrivateTmp=yes bash
Running as unit: run-u14.service
Press ^] three times within 1s to disconnect TTY.
[root@workstation /]# ls -l /tmp/
total 0
[root@workstation /]# ls -l /var/tmp/
total 0
[root@workstation /]# touch /tmp/f
[root@workstation /]# touch /var/tmp/f
touch: cannot touch '/var/tmp/f': Read-only file system
This commit has more changes than I like to put in one commit, but it's touching all
the same paths so it's hard to split.
exec_runtime_make() was using the wrong cleanup function, so the directory would be
left behind on error.
Now that we make the user/group name resolving available via userdb and
thus nss-systemd, we do not need the UID/GID resolving support in
nss-mymachines anymore. Let's drop it hence.
We keep the module around, since besides UID/GID resolving it also does
hostname resolving, which we care about. (One of those days we should
replace that by some Varlink logic between
nss-resolve/systemd-resolved.service too)
The hooks are kept in the NSS module, but they do not resolve anything
anymore, in order to keep compat at a maximum.
Let's move the heavy lifting out of the bus call implemntations, and
into generic code.
This allows us to expose them easily via Varlink too in a later commit.
sssd people don't like enumeration and for some other cases it's not
nice to support either, in particular when synthesizing records for
container/userns UID/GID ranges.
Hence, let's make enumeration optional.
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.
The test would always fail with a long uname. In F33 this is right
now "5.8.0-0.rc2.20200622git625d3449788f.1.fc33.x86_64" which caused the
test to always fail.
Commit b0ca726585 "rpm: avoid hiding errors from systemd commands" remove hiding errors and output
for other macros, but did not do that for %sysusers_create_package and %tmpfiles_create_package.
This change syncs their behaviour with %sysusers_create and %tmpfiles_create
Signed-off-by: Mikhail Novosyolov <m.novosyolov@rosalinux.ru>
The last line in this macros was actually "SYSTEMD_INLINE_EOF " with a space at the end,
but the shell was instructed to look for a line without space.
Macros %sysusers_create_inline and %tmpfiles_create_inline did not have this mistake.
An example:
[root@rosa-2019 bind-server]# cat /etc/passwd | grep named
[root@rosa-2019 bind-server]# cat /tmp/bs
systemd-sysusers --replace=/usr/lib/sysusers.d/named.conf - <<SYSTEMD_INLINE_EOF >/dev/null 2>&1 || :
u named - "BIND DNS Server" /var/lib/named
g named - -
m named named
SYSTEMD_INLINE_EOF
[root@rosa-2019 bind-server]# sh /tmp/bs
/tmp/bs: line 5: warning: here-document at line 1 delimited by end-of-file (wanted `SYSTEMD_INLINE_EOF')
[root@rosa-2019 bind-server]# bash /tmp/bs
/tmp/bs: line 5: warning: here-document at line 1 delimited by end-of-file (wanted `SYSTEMD_INLINE_EOF')
[root@rosa-2019 bind-server]# bash --version
GNU bash, version 5.0.17(1)-release (x86_64-openmandriva-linux-gnu)
The user and group named were NOT created!
Now I remove the trailing space after "SYSTEMD_INLINE_EOF" and rerun:
[root@rosa-2019 bind-server]# sh /tmp/bs
[root@rosa-2019 bind-server]# tail -n 1 /etc/group
named❌485:named
[root@rosa-2019 bind-server]#
The user and group have been created correctly.
Signed-off-by: Mikhail Novosyolov <m.novosyolov@rosalinux.ru>
Currently systemd-user-runtime-dir does not create the files in
/run/user/$UID/systemd/inaccessible with the default SELinux label.
The user and role part of these labels should be based on the user
related to $UID and not based on the process context of
systemd-user-runtime-dir.
Since v246-rc1 (9664be199a) /run/user/$UID/systemd is also created by
systemd-user-runtime-dir and should also be created with the default
SELinux context.
We never return anything higher than 63, so using "long unsigned"
as the type only confused the reader. (We can still use "long unsigned"
and safe_atolu() to parse the kernel file.)
We would refuse to print capabilities which were didn't have a name
for. The kernel adds new capabilities from time to time, most recently
cap_bpf. 'systmectl show -p CapabilityBoundingSet ...' would fail with
"Failed to parse bus message: Invalid argument" because
capability_set_to_string_alloc() would fail with -EINVAL. So let's
print such capabilities in hexadecimal:
CapabilityBoundingSet=cap_chown cap_dac_override cap_dac_read_search
cap_fowner cap_fsetid cap_kill cap_setgid cap_setuid cap_setpcap
cap_linux_immutable cap_net_bind_service cap_net_broadcast cap_net_admin
cap_net_raw cap_ipc_lock cap_ipc_owner 0x10 0x11 0x12 0x13 0x14 0x15 0x16
0x17 0x18 0x19 0x1a ...
For symmetry, also allow capabilities that we don't know to be specified.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1853736.
The call would always fail with:
systemd-userwork[780]: Failed to dlopen(libnss_systemd.so.2), ignoring: /usr/lib64libnss_systemd.so.2: cannot open shared object file: No such file or directory
Add support for creating a MACVLAN interface in "source" mode by
specifying Mode=source in the [MACVLAN] section of a .netdev file.
A list of allowed MAC addresses for the corresponding MACVLAN can also
be specified with the SourceMACAddress= option of the [MACVLAN] section.
An example .netdev file:
[NetDev]
Name=macvlan0
Kind=macvlan
MACAddress=02:DE:AD:BE:EF:00
[MACVLAN]
Mode=source
SourceMACAddress=02:AB:AB:AB:AB:01 02:CD:CD:CD:CD:01
SourceMACAddress=02:EF:EF:EF:EF:01
The same keys can also be specified in [MACVTAP] for MACVTAP kinds of
interfaces, with the same semantics.
Zbigniew Jędrzejewski-Szmek