So far all file systems where checked by instances of
systemd-fsck@.service, with the exception of the root fs which was
covered by systemd-fsck-root.service. The special handling is necessary
to deal with ordering issues: we typically want the root fs to be
checked before all others, and — weirdly — allow mounting it before the
fsck done (for compat with initrd-less boots).
This adds similar special handling for /usr: if the hierarchy is placed
on a separate file system check it with a special
systemd-fsck-usr.service instead of a regular sysemd-fsck@.service
instance. Reason is again ordering: we want to allow mounting of /usr
without the root fs already being around in the initrd, to cover for
cases where the root fs is created on first boot and thus cannot be
mounted/checked before /usr.
Let's exit early if we are invoked to generate an fsck unit for the
rootfs or /usr of the initrd itself. The "systemd-root-fsck.service" and
"systemd-usr-fsck.service" units are after all for the host file
systems, and the initrd file hierarchy is from an unpacked cpio anyway.
Hence, this semantically doesn't really make sense, so quickly exit if
we detect this case. This allows us to remove some checks further down
the codepath.
This tries to shorten the race of device reuse a bit more: let's ignore
udev database entries that are older than the time where we started to
use a loopback device.
This doesn't fix the whole loopback device raciness mess, but it makes
the race window a bit shorter.
This is similar to the preceding work to store the uevent seqnum, but
this stores the CLOCK_MONOTONIC timestamp.
Why? This allows to validate udev database entries, to determine if they
were created *after* we attached the device.
The uevent seqnum logic allows us to validate uevent, and the timestamp
database entries, hence together we should be able to validate both
sources of truth for us.
(note that this is all racy, just a bit less racy, since we cannot
atomically attach loopback devices and get the timestamp for it, the
same way we can't get the uevent seqnum. Thus is shortens the race
window, but doesn#t close it).
Let's drop all monitor uevent that were enqueued before we actually
started setting up the device.
This doesn't fix the race, but it makes the race window smaller: since
we cannot determine the uevent seqnum and the loopback attachment
atomically, there's a tiny window where uevents might be generated by
the device which we mistake for being associated with out use of the
loopback device.
Later, this will allow us to ignore uevents from earlier attachments a
bit better, as we can compare uevent seqnums with this boundary. It's
not a full fix for the race though, since we cannot atomically determine
the uevent and attach the device, but it at least shortens the window a
bit.
Previously, loop_device_make() would return the device fd in one success
code path, but not the other (where' we'd just return 0).
loop_device_open() returns it in all cases.
Hence, let's clean this up, and make sure in all success code paths of
both functions we return it (even though it strictly speaking is
redundant, since we return it in LoopDevice anyway, and currently noone
actually relies on this).
Even if we set up a loopback device read-only and mount it read-only
this means nothing, ext4 will still write through to the backing storage
file.
Yes, I lost 6h debugging time on this.
Apparently, we have to specify "norecovery" when mounting such file
systems, to force them into truly read-only mode. Let's do so.
Let's make the GPT partition flags configurable when creating new
partitions. This is primarily useful for the read-only flag (which we
want to set for verity enabled partitions).
This adds two settings for this: Flags= and ReadOnly=, which strictly
speaking are redundant. The main reason to have both is that usually the
ReadOnly= setting is the one wants to control, and it' more generic.
Moreover we might later on introduce inherting of flags from CopyBlocks=
partitions, where one might want to control most flags as is except for
the RO flag and similar, hence let's keep them separate.
Let's have one flag to request that when dissecting an image the
loopback device is made read-only, and another one to request that when
it is mounted to make it read-only. Previously both concepts were always
done read-only together.
(Of course, making the loopback device read-only but mounting it
read-write doesn't make too much sense, but the kernel should catch that
for us, no need to make restrictions from our side there)
Use-case for this: in systemd-repart we'd like to operate on images for
adding partitions. Thus we'd like to have the loopback device writable,
but if we read repart.d/ snippets from it, we want to do that read-only.
Let's assert if we ever happen to pass 0 to one of the log functions.
With the preceding commit to return -EIO from log_*(), passing 0 wouldn't
affect the return value any more, but it is still most likely an error.
The unit test code is an exception: we fairly often pass the return value
to print it, before checking what it is. So let's assert that we're not
passing 0 in non-test code. As with the previous check for %m, this is only
done in developer mode. We are depending on external code setting
errno correctly for us, which might not always be true, and which we can't
test, so we shouldn't assert, but just handle this gracefully.
I did a bunch of greps to try to figure out if there are any places where
we're passing 0 on purpose, and couldn't find any.
The one place that failed in tests is adjusted.
About "zerook" in the name: I wanted the suffix to be unambiguous. It's a
single "word" because each of the words in log_full_errno is also meaningful,
and having one term use two words would be confusing.
With some versions of the compiler, the _cleanup_ attr makes it think
the variable might be freed/closed when uninitialized, even though it
cannot happen. The added cost is small enough to be worth the benefit,
and optimized builds will help reduce it even further.
There are tokens with dots (and other symbols) in PKCS11 URI:
pkcs11:model=Rutoken%20ECP;manufacturer=Aktiv%20Co.;serial=3xxxxxxb;token=livelace
pkcs11:model=PRO;manufacturer=Aladdin%20R.D.;serial=CC62FB25;token=val%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00;id=%33%32%31%30%33%61%36%37%36%65%32%34%35%62%32%31;type=private
- Handle BPFProgram= property in string format
"<bpf_attach_type>:<bpffs_path>", e.g. egress:/sys/fs/bpf/egress-hook.
- Add dbus getter to list foreign bpf programs attached to a cgroup.
Introduce bpf_cgroup_attach_type_table with accustomed attached type
names also used in bpftool.
Add bpf_cgroup_attach_type_{from|to}_string helpers to convert from|to
string representation of pinned bpf program, e.g.
"egress:/sys/fs/bpf/egress-hook" for
/sys/fs/bpf/egress-hook path and BPF_CGROUP_INET_EGRESS attach type.
Add helpers to:
- Create new BPFProgram instance from a path in bpf
filesystem and bpf attach type;
- Pin a program to bpf fs;
- Get BPF program ID by BPF program FD.
gcc 9.3.0 "cc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0" with --optimization=1 was
not able to figure out that all cases are covered because r is either set in
the switch or type < _TABLE_DATA_TYPE_MAX.
But for a human reader this might also not be obvious: the cases are not in
exactly the same order as enum definitions, and it's a long list. By using the
goto, there should be no doubt, and we avoid checking the condition a second
time.
We forgot a call to dlopen_tpm2() in the unseal codepaths. As long as
automatic TPM2 device discovery was used that didn't matter, since in
that codepaths we'd have another call dlopen_tpm2(). But with an
explicitly configured TPM2 device things should work too, hence add the
missing call.
Fixes: #19206
The s390 PCI driver assigns the hotplug slot name from the
function_id attribute of the PCI device using a 8 char hexadecimal
format to match the underlying firmware/hypervisor notation.
Further, there's always a one-to-one mapping between a PCI
function and a hotplug slot, as individual functions can
hot plugged even for multi-function devices.
As the generic matching code will always try to parse the slot
name in /sys/bus/pci/slots as a positive decimal number, either
a wrong value might be produced for ID_NET_NAME_SLOT if
the slot name consists of decimal numbers only, or none at all
if a character in the range from 'a' to 'f' is encountered.
Additionally, the generic code assumes that two interfaces
share a hotplug slot, if they differ only in the function part
of the PCI address. E.g., for an interface with the PCI address
dddd:bb:aa.f, it will match the device to the first slot with
an address dddd:bb:aa. As more than one slot may have this address
for the s390 PCI driver, the wrong slot may be selected.
To resolve this we're adding a new naming schema version with the
flag NAMING_SLOT_FUNCTION_ID, which enables the correct matching
of hotplug slots if the device has an attribute named function_id.
The ID_NET_NAME_SLOT property will only be produced if there's
a file /sys/bus/pci/slots/<slotname> where <slotname> matches
the value of /sys/bus/pci/devices/.../function_id in 8 char
hex notation.
Fixes#19016
See also #19078
I want to tweak behaviour further, and that'll be easier when "style"
is converted to a bitfield.
Some callers used ESCAPE_BACKSLASH_ONELINE, and others not. But the
ones that didn't, simply didn't care, because the argument was assumed to
be one-line anyway (e.g. a service name). In environment-generator, this
could make a difference. But I think it's better to escape the newlines
there too. So newlines are now always escaped, to simplify the code and
the test matrix.
gcc was very unhappy for some reason:
[988/1664] Compiling C object systemd-oomd.p/src_oom_oomd.c.o
In file included from ../src/basic/path-util.h:10,
from ../src/shared/pretty-print.c:14,
from ../src/oom/oomd.c:15:
../src/shared/pretty-print.c: In function ‘conf_files_cat’:
../src/basic/strv.h:123:32: warning: ‘prefixes’ may be used uninitialized [-Wmaybe-uninitialized]
123 | for ((s) = (l); (s) && *(s); (s)++)
| ^
In file included from ../src/oom/oomd.c:15:
../src/shared/pretty-print.c:283:16: note: ‘prefixes’ was declared here
283 | char **prefixes, **prefix;
| ^~~~~~~~
../src/shared/pretty-print.c:305:12: warning: ‘is_collection’ may be used uninitialized in this function [-Wmaybe-uninitialized]
305 | if (!is_collection) {
| ^
../src/shared/pretty-print.c:301:13: warning: ‘extension’ may be used uninitialized in this function [-Wmaybe-uninitialized]
301 | r = conf_files_list_strv(&files, extension, root, 0, (const char* const*) dirs);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Maybe this is caused by the statis char** variables?
[1/429] Compiling C object src/shared/libsystemd-shared-248.a.p/bus-message-util.c.o
../src/shared/bus-message-util.c: In function ‘bus_message_read_dns_servers’:
../src/shared/bus-message-util.c:165:21: warning: ‘family’ may be used uninitialized in this function [-Wmaybe-uninitialized]
165 | r = in_addr_full_new(family, &a, port, 0, server_name, dns + n);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/shared/bus-message-util.c:165:21: warning: ‘port’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../src/shared/bus-message-util.c:165:21: warning: ‘server_name’ may be used uninitialized in this function [-Wmaybe-uninitialized]
The warning would be there despite all the asserts in bus_error_setfv() and
sd_bus_error_set(). So let's add an explicit assert.
