The comment about `SD_BUS_VTABLE_CAPABILITY(CAP_SYS_BOOT)` is
incorrect. To quote @YHNdnzj:
```
nah, the capability-based permission model is a legacy from kdbus. We cannot do it race-freely without it. Please simply drop the comment.
```
Thanks to @YHNdnzj for suggesting this.
The manager_do_set_objective() was doing a bunch of work to
check the `root` path that can already be done via
`json_dispatch_path` so instead of duplicating use the helper.
Thanks to @YHNdnzj for suggesting this.
Drop the _manager suffix for vl_method_{poweroff,{soft,}reboot,
halt,kexec}_manager.
They're unambiguous enough and the power mgmt operations are
not manager-wide but system-wide.
Thanks to @YHNdnzj for suggesting this.
networkctl previously called networkd over D-Bus for several operations.
This replaces all of those calls with Varlink, making it the sole IPC
mechanism between networkctl and networkd.
New Varlink methods added to networkd:
- io.systemd.Network.Link (new sub-interface for link-specific
operations):
- Link.Describe — replaces Link.BitRates + DHCPServer.Leases D-Bus
properties
- Link.Up — replaces Link.SetUp D-Bus method (moved from
**io.systemd.Network.LinkUp**)
- Link.Down — replaces Link.SetDown D-Bus method (moved from
**io.systemd.Network.LinkDown**)
- Link.Renew — replaces Link.Renew D-Bus method
- Link.ForceRenew — replaces Link.ForceRenew D-Bus method
- Link.Reconfigure — replaces Link.Reconfigure D-Bus method
- io.systemd.service
- Reload — replaces Manager.Reload D-Bus method
Supporting changes:
- link_get_bit_rates() extracted from networkd-link.c into
networkd-speed-meter.c
- BitRates added to link_build_json() so Link.Describe returns them
inline
alongside the existing interface description, replacing a separate D-Bus
read
- link_reconfigure_full() and manager_reload() extended to accept
sd_varlink*
for deferred async replies (consistent with existing sd_bus_message*
path)
- DHCP lease display (networkctl status) uses Link.Describe instead of
DHCPServer.Leases; falls back to ClientId when hostname is not present
This is not actually used so it doesn't really matter in
practice and the fields are used anyway, but for cleanliness
fix it
Reported on yeswehack.com as YWH-PGM9780-165
Follow-up for 5699a1689b
systemd now has a system call wrapper that does a long series of #ifdef's to
differentiate between architectures and ABIs. This wrapper has two problems.
1. On mips, it needs to differentiate between O32, N32, N64 ABI. It does that
via a code block in src/include/override/sys/generate-syscall.py (and derived
files):
76 # elif defined(_MIPS_SIM)
77 # if _MIPS_SIM == _MIPS_SIM_ABI32
78 # define systemd_NR_{syscall} {nr_mipso32}
79 # elif _MIPS_SIM == _MIPS_SIM_NABI32
80 # define systemd_NR_{syscall} {nr_mips64n32}
81 # elif _MIPS_SIM == _MIPS_SIM_ABI64
82 # define systemd_NR_{syscall} {nr_mips64}
83 # else
84 # error "Unknown MIPS ABI"
85 # endif
86 # elif defined(__hppa__)
Now the _MIPS_SIM* constants stem from a vendor-specific header file sgidefs.h,
which is included with glibc, but not with musl. It is however always present
in the Linux kernel headers as asm/sgidefs.h ...
2. To work around this, the syscall wrapper already has a block
47 #ifdef ARCH_MIPS
48 #include <asm/sgidefs.h>
49 #endif
Turns out, ARCH_MIPS is defined nowhere in Gentoo, neither on glibc nor on musl.
As a result the code (by accident, probably sgidefs.h is included transitively
somehow) works on glibc, but not on musl.
The simplest fix is to replace line 47 in the generator and the derived file
with
47 #ifdef __mips__
Two other source code files require a similar fix since they rely on the
constants.
Bug: https://github.com/systemd/systemd/issues/41239
Bug: https://bugs.gentoo.org/971376
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
The commit 6d7cb9a6b8 fixes the assignment
of the these options when specified through SendOption=. However, it
breaks when specified through UserClass= or SendVendorOption=.
When UserClass= or SendVendorOption= is specified, the option length is
calculated from the sd_dhcp_client.user_class or .vendor_options. Hence,
we can use 0 for the length in that case.
Follow-up for 6d7cb9a6b8.
This commit allows unset pidref when calling manager_log_caller().
With that we can log manager calls even if we cannot resolve the
caller. Currently when we cannot resolve the caller we are just
not logging anything. With this commit we at least log the call
(even though we don't know what caller it was).
Thanks to keszybz for the suggestion.
Extract a common helper varlink_log_caller() and use in the varlink
code when logging the caller of a method. It also logs the method
now that was tried (but failed) to be logged with log_notice just
like manager_log_caller() would do.
I was looking into modifying `manager_log_caller` instead and
accept a NULL pidref but could not log more than the method without
pidref and would make the manager_log_caller slightly less nice.
Thanks to keszybz for suggesting this.
This adds the low-level io.systemd.Manager shutdown support. This
is (much) simpler than the logind one. It mimics dbus but uses
a shared helper for the simple cases.
Note that this is more restrictive than the dbus version. The
dbus version uses SD_BUS_VTABLE_CAPABILITY(CAP_SYS_BOOT) but
the varlink version uses varlink_check_privileged_peer(link).
This is mostly because I'm not sure how to do the equivalent
in a race-free way.
Thanks to Daan for suggesting this.
dns_packet_unref() unconditionally unrefs p->more on every call,
even when n_ref > 1. But dns_packet_ref() doesn't ref p->more.
This means if a packet with a ->more chain gets ref'd and unref'd
multiple times, the chain gets freed too early while the parent
still holds a dangling pointer.
Move the p->more unref into the n_ref == 1 block so the chain
only gets cleaned up when the packet is actually being freed.
Call client_stop() on error and return 0 only on callback.
Normal non-callback functions should propagate errors.
This also makes client_initialize_time_events() use
event_reset_time_relative().
FORCERENEW message support has been disabled so long time for security
concern. Most other implementations of DHCP server/client neither
support FORCERENEW. Let's completely drop relevant code.
Loading vmw_vsock_virtio_transport early at boot causes vsock to be
resident before any application opens an AF_VSOCK socket. Because the
kernel skips autoloading when the vsock module is already present,
vsock_loopback never gets loaded automatically, and any subsequent
bind() to VMADDR_CID_LOCAL fails with EADDRNOTAVAIL.
Fix this by explicitly loading vsock_loopback on virtio or VMWare
machines via the new may_have_vsock_looopback() helper, wich covers both
vmw_vsock_virtio_transport and vmware_vsock_vmci_transport case.
vsock_loopback is the only module that registers a transport for
VMADDR_CID_LOCAL (CID 1) and has no hard dependency from any of the
vsock transport modules.
Fixes: #41100
Follow-up for 381c78db491a7c5fad8697543dd36ebe9b848718
CAP_SYS_PTRACE for making sure we can open mount namespaces of
peers via /proc/<pid>/ns and CAP_SYS_CHROOT for making sure we can
join those mount namespaces.
The match in "AYA NEO" will never happen as dmi modalias will wipe blank
spaces. Even more the intended match was covered before by "AYANEO".
Actually there are contributions that rely on someone giving some data
to other someone with no test at all.
Should be consider to enforce the full udevadm info --export-db as
mandatory requirement fot this kind of contributions.
The number of integrity algorithms we handle whose names differ between
integritysetup and dm-integrity continually increases, so let's drop the
ad hoc conversion and use string tables.
In one of the reviews one of the LLMs noticed that the pragma is set but
never unset, so it remains in effect for the rest of the translation
unit. From the comment, it's not clear how old those "old compilers"
were, so let's try if things work without this workaround.
It has been observed on some systems[1] that ssh-issue may print out:
Try contacting this VM's SSH server via 'ssh vsock%4294967295' from host.
i.e. it suggests connecting with VMADDR_CID_ANY, which is not valid. It
seems that IOCTL_VM_SOCKETS_GET_LOCAL_CID may return VMADDR_CID_ANY in
some cases, e.g. when vsock is not full initialized or so.
Treat VMADDR_CID_ANY as special in vsock_get_local_cid(), the same as
VMADDR_CID_LOCAL and VMADDR_CID_HOST, and return an error.
[1] https://launchpad.net/bugs/2145027
Right now, if a user tries to pass VMADDR_CID_ANY to systemd-ssh-proxy,
an assert is triggered:
$ ssh vsock%4294967295
Assertion 'cid != VMADDR_CID_ANY' failed at src/ssh-generator/ssh-proxy.c:21, function process_vsock_cid(). Aborting.
mm_receive_fd: recvmsg: expected received 1 got 0
proxy dialer did not pass back a connection
This is becauase the value returned from vsock_parse_cid is not checked
before being passed to process_vsock_string. Add a check to prevent
that.
Typically, the top-level JSON object has to be an object, in any json
document we parse, hence let's add a simple way to enforce that.
Make use of this in various places.
(Note, various other JSON parsers insist on this logic right from the
beginning, but I actually thinking making this insisting optional like
this patch does it is the cleaner approach)
Also, in general we prefer variables that are always defined over
checking with #ifdef, so #if defined(HAVE_NO_STACK_PROTECTOR_ATTRIBUTE)
is something that we want to avoid.
This attribute was introduced in gcc 11, and our baseline is currently
8.4. So let's allow using _retain_ everywhere, but make it into a noop
if not supported.
Using __has_attribute was suggested, but with gcc-11.5.0-14.el9.x86_64,
__has__attribute(__retain__) is true, but we get a warning when the
attribute is actually used.
dbus-daemon intentionally disconnects peers when FDs get
truncated. Detect it and skip it in that case, as the purpose
of the test is not to exercise the D-Bus implementation, but
our library.
When running with dbus-broker (Fedora, etc) we'll get full
coverage.
Fixes https://github.com/systemd/systemd/issues/41150
Follow-up for 744d589632
For the IMDS case there's value in being able to set the static
hostname, instead of just the transient one. Let's introduce
firstboot.hostname, which only applies to first boot, and write the
static hostname. This is different from system.hostname which applies to
any boot, and writes the transient hostname.