Unlike most other bus connections in our codebase this one is created
manually and every setting set invididually. It hence does not have a
description by default (as all automatic connections have). Set one
explicitly.
Now that clients might convey comm/description strings via the sockaddr,
let's actually use them on the other side, read the data via
getpeername() parse it, and include it in the "owner" creds (which is
how we call the peer's creds).
Otherwise hilarity ensues:
AddressSanitizer:DEADLYSIGNAL
=================================================================
==722==ERROR: AddressSanitizer: SEGV on unknown address 0xffffffff00000000 (pc 0x7f8d50ca9ffb bp 0x7fff11b0d4a0 sp 0x7fff11b0cc30 T0)
==722==The signal is caused by a READ memory access.
#0 0x7f8d50ca9ffb in __interceptor_strcmp.part.0 (/lib64/libasan.so.8+0xa9ffb)
#1 0x7f8d4f9cf5a1 in strcmp_ptr ../src/fundamental/string-util-fundamental.h:33
#2 0x7f8d4f9cf5f8 in streq_ptr ../src/fundamental/string-util-fundamental.h:46
#3 0x7f8d4f9d74d2 in free_and_strdup ../src/basic/string-util.c:948
#4 0x49139a in free_and_strdup_warn ../src/basic/string-util.h:197
#5 0x4923eb in oci_absolute_path ../src/nspawn/nspawn-oci.c:139
#6 0x7f8d4f6bd359 in json_dispatch ../src/shared/json.c:4395
#7 0x4a8831 in oci_hooks_array ../src/nspawn/nspawn-oci.c:2089
#8 0x7f8d4f6bd359 in json_dispatch ../src/shared/json.c:4395
#9 0x4a8b56 in oci_hooks ../src/nspawn/nspawn-oci.c:2112
#10 0x7f8d4f6bd359 in json_dispatch ../src/shared/json.c:4395
#11 0x4aa298 in oci_load ../src/nspawn/nspawn-oci.c:2197
#12 0x446cec in load_oci_bundle ../src/nspawn/nspawn.c:4744
#13 0x44ffa7 in run ../src/nspawn/nspawn.c:5477
#14 0x4552fb in main ../src/nspawn/nspawn.c:5920
#15 0x7f8d4e04a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
#16 0x7f8d4e04a5c8 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x275c8)
#17 0x40d284 in _start (/usr/bin/systemd-nspawn+0x40d284)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib64/libasan.so.8+0xa9ffb) in __interceptor_strcmp.part.0
==722==ABORTING
Use the returned errno even though we are going to ignore it, otherwise
the log message is just confusing:
config.json:119:13: Failed to resolve device node 4:2, ignoring: Success
When merging the settings we take the pointer to the array of extra
devices, but don't reset the array counter to zero. This later leads to
a NULL pointer dereference, where device_node_array_free() attempts to
loop over a NULL pointer:
+ systemd-nspawn --oci-bundle=/var/lib/machines/testsuite-13.oci-bundle.Npo
../src/nspawn/nspawn-settings.c:118:29: runtime error: member access within null pointer of type 'struct DeviceNode'
#0 0x4b91ee in device_node_array_free ../src/nspawn/nspawn-settings.c:118
#1 0x4ba42a in settings_free ../src/nspawn/nspawn-settings.c:161
#2 0x410b79 in settings_freep ../src/nspawn/nspawn-settings.h:249
#3 0x446ce8 in load_oci_bundle ../src/nspawn/nspawn.c:4733
#4 0x44ff42 in run ../src/nspawn/nspawn.c:5476
#5 0x455296 in main ../src/nspawn/nspawn.c:5919
#6 0x7f0cb7a4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
#7 0x7f0cb7a4a5c8 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x275c8)
#8 0x40d284 in _start (/usr/bin/systemd-nspawn+0x40d284)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/nspawn/nspawn-settings.c:118:29 in
Also, add an appropriate assert to catch such issues in the future.
Let's pass some additional meta information along bus connections
without actually altering the communication protocol.
Pass the client comm and client description string of the bus via
including it in the abstract namespace client socket address we connect
to. This is purely informational (and entirely user controlled), but has
the benefit that servers can make use of the information if they want,
but really don't have to. It works entirely transparently.
This takes inspiration from how we convey similar information via
credential socket connections.
Previously, we first assign alternative names to a network interface,
then later change its main name if requested. So, we could not assign
the name that currently assigned as the main name of an interface as an
alternative name. So, we retry to assign the previous main name as an
alternative name on later move uevent.
However, that causes some confusing situation. E.g. if a .link file has
```
Name=foo
AlternativeNames=foo baz
```
then even if the interface is renamed by a user e.g. by invoking 'ip link'
command manually, the interface can be still referenced as 'foo', as the
name is now assigned as an alternative name.
This makes the order of name assignment inverse: the main name is first
changed, and then the requested alternative names are assigned. And
udevd do not assign alternative names on move uevent.
Replaces #27506.
Let's use the same common directory as the unit logic uses.
This means we have less to clean up, and opens the door to eventually
allow unprivileged operation of the
mount_image_privately_interactively() logic.
This creates a new dir /run/systemd/mount-rootfs/ early in PID 1 that
thus always exists. It's supposed to be used by any code that creates
its own mount namespace and then sets up a new root dir to switch into.
So far in many cases we used a temporary dir (which needed explicit
clean-up) or a purpose-specific fixed dir.
Let's create a common dir instead, that always exists (as it is created
in PID 1 early on, always).
Besides making things more robust, as manual clean-up of the inode is
not necessary anymore this also opens the door for unprivileged programs
to use the same dir, since it now always exists.
Set the access mode to 555 (instead of the otherwise previously used
0755, 0700 or similar), so that unprivileged programs can access it, but
we make clear it's not supposed to be written directly to, by anyone,
not even root.
We provide the same stability for all the headers that are public.
Also, mark id128 as portable to other systems. There is really nothing in the
code that would make it hard. It would probably work out-of-the-box.
Before libsystemd-daemon, libsystemd-journal, libsystemd-id128, etc., were
merged into libsystemd, it was enough to have individual man pages for them.
But they have been delivered as one thing for many years, so it's better to
have a landing page for libsystemd. It mostly directs to individual pages
anyway.
If we change the watchdog device we should disarm the old one first.
Similar, if we open the watchdog, but then fail setting it up, disarm it
before closing it again.
