These three syscalls are internally used by libc's memory allocation
logic, i.e. ultimately back malloc(). Allocating a bit of memory is so
basic, it should just be in the default set.
This fixes a couple of issues with asan/msan and the seccomp tests: when
asan/msan is used some additional, large memory allocations take place
in the background, and unless mmap/mmap2/brk are allowlisted these will
fail, aborting the test prematurely.
This reverts commit 34136e1503.
Having the "%H" host name specifier in a DNSSD service name template
triggers a failed assertion during name template instantiation as
specifier_dnssd_host_name expects DnssdService in its userdata
pointer but finds NULL instead.
test_oomd_cgroup_context_acquire_and_insert reads the live cgroup data used
by the unit test. Under certain conditions, the memory pressure for the cgroup
can be non-zero (although most of the time it is 0 since these tests don't
generate much pressure).
Since these values are too dependent on the state of the system, remove the
checks. The type used is always >= 0 and test-psi-util already unit tests that
PSI values are parsed correctly from files so this test is redundant anyways.
Follow-up for ac24e418d9.
The original motivation of the commit and RFE #15339 is to start dhcpv6
client in managed mode when neither M nor O flag is set in the RA.
But, previously, if the setting is set to "always", then the DHCPv6
client is always started in managed mode even if O flag is set in the
RA. Such the behavior breaks RFC 7084.
The configuration of networkd has a DHCPv6Client setting in its
[IPv6AcceptRA] section, which, according to the man page, can be
a boolean, or the special value "always". The man page states
that "true" is the default.
The default value is implemented in src/network/networkd-network.c
by setting field ipv6_accept_ra_start_dhcp6_client of network to
true. However, this field is not a boolean, but an enum type
IPv6AcceptRAStartDHCP6Client (src/network/networkd-ndisc.h).
Setting ipv6_accept_ra_start_dhcp6_client to true effectively
corresponds to the enum value IPV6_ACCEPT_RA_START_DHCP6_CLIENT_ALWAYS,
resulting in the DHCPv6Client setting having the default value
"always".
This patch changes the initialisation to the correct enum value
IPV6_ACCEPT_RA_START_DHCP6_CLIENT_YES.
This is useful for development where overwriting files out side
the configured prefix will affect the host as well as stateless
systems such as NixOS that don't let packages install to /etc but handle
configuration on their own.
Alternative to https://github.com/systemd/systemd/pull/17501
tested with:
$ mkdir inst build && cd build
$ meson \
-Dcreate-log-dirs=false \
-Dsysvrcnd-path=$(realpath ../inst)/etc/rc.d \
-Dsysvinit-path=$(realpath ../inst)/etc/init.d \
-Drootprefix=$(realpath ../inst) \
-Dinstall-sysconfdir=false \
--prefix=$(realpath ../inst) ..
$ ninja install
":" is prettier, but meson 0.56+ doesn't like it:
src/systemd/meson.build:73: DEPRECATION: ":" is not allowed in test name "cc-sd-bus.h:c", it has been replaced with "_"
src/systemd/meson.build:73: DEPRECATION: ":" is not allowed in test name "cc-sd-bus.h:c-ansi", it has been replaced with "_"
...
Fixes#17568.
With the grandparent change to move most units to app.slice,
those units would be ordered After=app.slice which doesn't make any sense.
Actually they appear earlier, before the manager is even started, and
conceputally it doesn't seem useful to put them under any slice.
... when called with a valid environment variable name. This means that
any time we call it with a fixed string, it is guaranteed to return 0.
(Also when the variable is not present in the environment block.)
Coverity in CID#1435966 was complaining that s->enabled is not "restored" in
all cases. But the code was actually correct, since it should only be
"restored" in the error paths. But let's still make this prettier by not setting
the state before all operations that may fail are done.
We need to set .enabled for the prioq reshuffling operations, so move those down.
No functional change intended.
There are downsides to using fexecve:
when fexecve is used (for normal executables), /proc/pid/status shows Name: 3,
which means that ps -C foobar doesn't work. pidof works, because it checks
/proc/self/cmdline. /proc/self/exe also shows the correct link, but requires
privileges to read. /proc/self/comm also shows "3".
I think this can be considered a kernel deficiency: when O_CLOEXEC is used, this
"3" is completely meaningless. It could be any number. The kernel should use
argv[0] instead, which at least has *some* meaning.
I think the approach with fexecve/execveat is instersting, so let's provide it
as opt-in.
For scripts, when we call fexecve(), on new kernels glibc calls execveat(),
which fails with ENOENT, and then we fall back to execve() which succeeds:
[pid 63039] execveat(3, "", ["/home/zbyszek/src/systemd/test/test-path-util/script.sh", "--version"], 0x7ffefa3633f0 /* 0 vars */, AT_EMPTY_PATH) = -1 ENOENT (No such file or directory)
[pid 63039] execve("/home/zbyszek/src/systemd/test/test-path-util/script.sh", ["/home/zbyszek/src/systemd/test/test-path-util/script.sh", "--version"], 0x7ffefa3633f0 /* 0 vars */) = 0
But on older kernels glibc (some versions?) implement a fallback which falls
into the same trap with bash $0:
[pid 13534] execve("/proc/self/fd/3", ["/home/test/systemd/test/test-path-util/script.sh", "--version"], 0x7fff84995870 /* 0 vars */) = 0
We don't want that, so let's call execveat() ourselves. Then we can do the
execve() fallback as we want.
Previously it was very likely, when multiple contenders for the symlink
appear in parallel, that algorithm would select wrong symlink (i.e. one
with lower-priority).
Now the algorithm is much more defensive and when we detect change in
set of contenders for the symlink we reevaluate the selection. Same
happens when new symlink replaces already existing symlink that points
to different device node.
Note that st_mtime member of struct stat is defined as follows,
#define st_mtime st_mtim.tv_sec
Hence we omitted checking nanosecond part of the timestamp (struct
timespec) and possibly would miss modifications that happened within the
same second.
FixedRandomDelay=yes will use
`siphash24(sd_id128_get_machine() || MANAGER_IS_SYSTEM(m) || getuid() || u->id)`,
where || is concatenation, instead of a random number to choose a value between
0 and RandomizedDelaySec= as the timer delay.
This essentially sets up a fixed, but seemingly random, offset for each timer
iteration rather than having a random offset recalculated each time it fires.
Closes#10355
Co-author: Anita Zhang <the.anitazha@gmail.com>
Quoting the manual page of stime(2): "Starting with glibc 2.31, this function
is no longer available to newly linked applications and is no longer declared
in <time.h>."
If we encounter an RR that has no matching signature, then we don't know
whether it was expanded from a wildcard or not. We need to accept that
and not make the NSEC test fail, just skip over the RR.
The three answer sections can only carry up to UINT16_MAX entries, hence
put a hard upper limit on how far DnsAnswer can grow. The three count
fields in the DNS packet header are 16 bit only, hence the limit.
If code actually tries to add more than 64K RRs it will get ENOSPC with
this new checking.
And similar to DnsQuestion.
The current overflow checking is broken in the corner case of the strings'
combined length being exactly SIZE_MAX: After the loop, l would be SIZE_MAX,
but we're not testing whether the l+1 expression overflows.
Fix it by simply pre-accounting for the final '\0': initialize l to 1 instead
of 0.
The loops over (x, then all varargs, until a NULL is found) can be written much
simpler with an ordinary for loop. Just initialize the loop variable to x, test
that, and in the increment part, fetch the next va_arg(). That removes a level
of indentation, and avoids doing a separate strlen()/stpcpy() call for x.
While touching this code anyway, change (size_t)-1 to the more readable
SIZE_MAX.
This beefs up the READ_FULL_FILE_CONNECT_SOCKET logic of
read_full_file_full() a bit: when used a sender socket name may be
specified. If specified as NULL behaviour is as before: the client
socket name is picked by the kernel. But if specified as non-NULL the
client can pick a socket name to use when connecting. This is useful to
communicate a minimal amount of metainformation from client to server,
outside of the transport payload.
Specifically, these beefs up the service credential logic to pass an
abstract AF_UNIX socket name as client socket name when connecting via
READ_FULL_FILE_CONNECT_SOCKET, that includes the requesting unit name
and the eventual credential name. This allows servers implementing the
trivial credential socket logic to distinguish clients: via a simple
getpeername() it can be determined which unit is requesting a
credential, and which credential specifically.
Example: with this patch in place, in a unit file "waldo.service" a
configuration line like the following:
LoadCredential=foo:/run/quux/creds.sock
will result in a connection to the AF_UNIX socket /run/quux/creds.sock,
originating from an abstract namespace AF_UNIX socket:
@$RANDOM/unit/waldo.service/foo
(The $RANDOM is replaced by some randomized string. This is included in
the socket name order to avoid namespace squatting issues: the abstract
socket namespace is open to unprivileged users after all, and care needs
to be taken not to use guessable names)
The services listening on the /run/quux/creds.sock socket may thus
easily retrieve the name of the unit the credential is requested for
plus the credential name, via a simpler getpeername(), discarding the
random preifx and the /unit/ string.
This logic uses "/" as separator between the fields, since both unit
names and credential names appear in the file system, and thus are
designed to use "/" as outer separators. Given that it's a good safe
choice to use as separators here, too avoid any conflicts.
This is a minimal patch only: the new logic is used only for the unit
file credential logic. For other places where we use
READ_FULL_FILE_CONNECT_SOCKET it is probably a good idea to use this
scheme too, but this should be done carefully in later patches, since
the socket names become API that way, and we should determine the right
amount of info to pass over.
When selinux is enabled, the call of
manager_rtnl_enumerate_nexthop() fails.
This fix is to facilitate selinux hook handling for enumerating
nexthop.
In manager_rtnl_enumerate_nexthop() there is a check
if "Not supported" is returned by the send_netlink() call.
This check expects that -EOPNOTSUPP is returned,
the selinux hook seems to return -EINVAL instead.
This happens in kernel older than 5.3
(more specificallytorvalds/linux@65ee00a) as it does not support
nexthop handling through netlink.
And if SELinux is enforced in the order kernel, callingRTM_GETNEXTHOP
returns -EINVAL.
Thus adding a call in the manager_rtnl_enumerate_nexthop for the
extra return -EINVAL.
* Existing valid rule files written with KEY="value" are not affected
* Now, KEY=e"value\n" becomes valid. Where `\n` is a newline character
* Escape sequences supported by src/basic/escape.h:cunescape() is
supported
With these patches applied, networkd is successfully able to get an
address from a DHCP server on an IPoIB interface.
1)
Makes networkd pass the actual interface type to the dhcp client,
instead of hardcoding it to Ethernet.
2)
Fixes some issues in handling the larger (20 Byte) IB MAC addresses in
the dhcp code.
3)
Add a new field to networkds Link struct, which holds the interface
broadcast address.
3.1)
Modify the DHCP code to also expect the broadcast address as parameter.
On an Ethernet-Interface the Broadcast address never changes and is always
all 6 bytes set to 0xFF.
On an IB one however it is not neccesarily always the same, thus
fetching the actual address from the interface is neccesary.
4)
Only the last 8 bytes of an IB MAC are stable, so when using an IB MAC to
generate a client ID, only pass those 8 bytes.
This passes the legacy ethernet address to functions in a lot of places,
which all will need migrated to handle arbitrary size hardware addresses
eventually.
Hardware addresses come in various shapes and sizes, these new functions
and accomapying data structures account for that instead of hard-coding
a hardware address to the 6 bytes of an ethernet MAC.
The link state file is always removed when networkd is stopping. So,
the deserialization logic does not work. Moreover, the ADDRESSES=
entry is not used by sd-network, so serialization is also not necessary.
The link state file is always removed on stop. So, we cannot deserialize
the address from the file. Moreover, currently the IPv4 link-local address
is always dropped by link_drop_foreign_addresses() on restart. Let's
drop the serialize/deserialize logic for IPv4 LL address.
Previously, the address was taken from the state file, but DHCP4_ADDRESS=
entry was dropped by 46986251d6.
Moreover, the link state file is always removed when networkd is
stopping. Let's take the address from the list of enumerated addresses.
Ideally, we'd read back what we wrote, but that would have been
much more complicated. But just writing stuff is useful to test under
valgrind or manually.
We had two of each: both homectl and journalctl had the whole dlopen()
wrapper, and journalctl had two implementations (slightly different) of the
code to print the fss:// pattern.
print_qrcode() now returns -EOPNOTSUPP when compiled with qrcode support. Both
callers ignore the return value, so this changes nothing.
No functional change.
This adds a way to control SO_TIMESTAMP/SO_TIMESTAMPNS socket options
for sockets PID 1 binds to.
This is useful in journald so that we get proper timestamps even for
ingress log messages that are submitted before journald is running.
We recently turned on packet info metadata from PID 1 for these sockets,
but the timestamping info was still missing. Let's correct that.
Let's not have #ifdeffery both in the consumers and the providers of the
selinux glue code. Unless the code is particularly complex, let's do the
ifdeffery only in the provider of the selinux glue code, and let's keep
the consumers simple and just invoke it.
So far half of sd_event_source_set_enabled() was doing enabling, the
other half was doing disabling. Let's split that into two separate
calls.
(This also adds a new shortcut to sd_event_source_set_enabled(): if the
caller toggles between "ON" and "ONESHOT" we'll now shortcut this, since
the event source is already enabled in that case and shall remain
enabled.)
This heavily borrows and is inspired from Michal Sekletár's #17284
refactoring.
We typically don't just reshuffle a single prioq at once, but always
two. Let's add two helper functions that do this, and reuse them
everywhere.
(Note that this drops one minor optimization:
sd_event_source_set_time_accuracy() previously only reshuffled the
"latest" prioq, since changing the accuracy has no effect on the
earliest time of an event source, just the latest time an event source
can run. This optimization is removed to simplify things, given that
it's not really worth the effort as prioq_reshuffle() on properly
ordered prioqs has practically zero cost O(1)).
(Slightly generalized, commented and split out of #17284 by Lennart)
This reverts commit 6c5496c492.
sysinit.target is shared between the initrd and the host system. Pulling in
initrd-cryptsetup.target into sysinit.target causes the following warning at
boot:
Oct 27 10:42:30 workstation-uefi systemd[1]: initrd-cryptsetup.target: Starting requested but asserts failed.
Oct 27 10:42:30 workstation-uefi systemd[1]: Assertion failed for initrd-cryptsetup.target.
If processes remain in the unit's cgroup after the final SIGKILL is
sent and the unit has exceeded stop timeout, don't release the unit's
cgroup information. Pid1 will have failed to `rmdir` the cgroup path due
to processes remaining in the cgroup and releasing would leave the cgroup
path on the file system with no tracking for pid1 to clean it up.
Instead, keep the information around until the last process exits and pid1
sends the cgroup empty notification. The service/scope can then prune
the cgroup if the unit is inactive/failed.
Ubuntu builds on the Launchpad infrastructure run inside a chroot that does
not have the sysfs cgroup dirs mounted, so this call will return ENOMEDIUM
from cg_unified_cached() during the build-time testing, for example when
building the package in a Launchpad PPA.
This effectively reverts the commit 22fc2420b2.
The function `asynchronous_close()` confuses valgrind. Before this commit,
valgrind may report the following:
```
HEAP SUMMARY:
in use at exit: 384 bytes in 1 blocks
total heap usage: 4,787 allocs, 4,786 frees, 1,379,191 bytes allocated
384 bytes in 1 blocks are possibly lost in loss record 1 of 1
at 0x483CAE9: calloc (vg_replace_malloc.c:760)
by 0x401456A: _dl_allocate_tls (in /usr/lib64/ld-2.31.so)
by 0x4BD212E: pthread_create@@GLIBC_2.2.5 (in /usr/lib64/libpthread-2.31.so)
by 0x499B662: asynchronous_job (async.c:47)
by 0x499B7DC: asynchronous_close (async.c:102)
by 0x4CFA8B: client_initialize (sd-dhcp-client.c:696)
by 0x4CFC5E: client_stop (sd-dhcp-client.c:725)
by 0x4D4589: sd_dhcp_client_stop (sd-dhcp-client.c:2134)
by 0x493C2F: link_stop_clients (networkd-link.c:620)
by 0x4126DB: manager_free (networkd-manager.c:867)
by 0x40D193: manager_freep (networkd-manager.h:97)
by 0x40DAFC: run (networkd.c:20)
LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 384 bytes in 1 blocks
still reachable: 0 bytes in 0 blocks
suppressed: 0 bytes in 0 blocks
For lists of detected and suppressed errors, rerun with: -s
ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
```
This reverts commit b45c068dd8.
I think the idea was generally sound, but didn't take into account the
limitations of show-environment and how it is used. People expect to be able to
eval systemctl show-environment output in bash, and no escaping syntax is
defined for environment *names* (we only do escaping for *values*). We could
skip such problematic variables in 'systemctl show-environment', and only allow
them to be inherited directly. But this would be confusing and ugly.
The original motivation for this change was that various import operations
would fail. a4ccce22d9 changed systemctl to filter
invalid variables in import-environment.
https://gitlab.gnome.org/GNOME/gnome-session/-/issues/71 does a similar change
in GNOME. So those problematic variables should not cause failures, but just
be silently ignored.
Finally, the environment block is becoming a dumping ground. In my gnome
session 'systemctl show-environment --user' includes stuff like PWD, FPATH
(from zsh), SHLVL=0 (no idea what that is). This is not directly related to
variable names (since all those are allowed under the stricter rules too), but
I think we should start pushing people away from running import-environment and
towards importing only select variables.
https://github.com/systemd/systemd/pull/17188#issuecomment-708676511
This changes the default from putting all units into the root slice to
placing them into the app slice in the user manager. The advantage is
that we get the right behaviour in most cases, and we'll need special
case handling in all other cases anyway.
Note that we have currently defined that applications *should* start
their unit names with app-, so we could also move only these by creating
a drop-in for app-.scope and app-.service.
However, that would not answer the question on how we should manage
session.slice. And we would end up placing anything that does not fit
the system (e.g. anything started by dbus-broker currently) into the
root slice.
These should not be bundled into the link_up() operation, as that is
not (currently) called during interface configuration if the interface
already is IFF_UP, which is unrelated to the need to change the mac
to a user-defined value, or set 'nomaster' on the interface.
Additionally, there is no need to re-set the mac or re-assert nomaster
every time the interface is brought up; those should be only part of
normal initial interface configuration.
Fixes: #17391
Let's try to make collisions when multiple clients want to use the same
device less likely, by sleeping a random time on collision.
The loop device allocation protocol is inherently collision prone:
first, a program asks which is the next free loop device, then it tries
to acquire it, in a separate, unsynchronized setp. If many peers do this
all at the same time, they'll likely all collide when trying to
acquire the device, so that they need to ask for a free device again and
again.
Let's make this a little less prone to collisions, reducing the number
of failing attempts: whenever we notice a collision we'll now wait
short and randomized time, making it more likely another peer succeeds.
(This also adds a similar logic when retrying LOOP_SET_STATUS64, but
with a slightly altered calculation, since there we definitely want to
wait a bit, under all cases)
On systems that have a udev before
a7fdc6cbd3 uevents would sometimes be
eaten because of device node collisions that caused the ruleset to fail.
Let's add an (ugly) work-around for this, so that we can even work with
such an older udev.
On current kernels (5.8 for example) under some conditions I don't fully
grok it might happen that a detached loopback block device still has
partition block devices around. Accessing these partition block devices
results in EIO errors (that also fill up dmesg). These devices cannot be
claned up with LOOP_CLR_FD (since the main device already is officially
detached), nor with LOOP_CTL_DELETE (returns EBUSY as long as the
partitions still exist). This is a kernel bug. But it appears to apply
to all recent kernels. I cannot really pin down what triggers this,
suffice to say our heavy-duty test can trigger it.
Either way, let's do something about it: when we notice this state we'll
attach an empty file to it, which is guaranteed to have to part table.
This makes the partitions go away. After closing/reoping the device we
hence are good to go again. ugly workaround, but I think OK enough to
use.
The net result is: with this commit, we'll guarantee that by the time we
attach a file to the loopback device we have zero kernel partitions
associated with it. Thus if we then wait for the kernel partitions we
need to appear we should have entirely reliable behaviour even if
loopback devices by the name are heavily recycled and udev events reach
us very late.
Fixes: #16858
Previously, we'd just wait for the first moment where the kernel exposes
the same numbre of partitions as libblkid tells us. After that point we
enumerate kernel partitions and look for matching libblkid partitions.
With this change we'll instead enumerate with libblkid only, and then
wait for each kernel partition to show up with the exact parameters we
expect them to show up. Once that happens we are happy.
Care is taken to use the udev device notification messages only as hint
to recheck what the kernel actually says. That's because we are
otherwise subject to a race: we might see udev events from an earlier
use of a loopback device. After all these devices are heavily recycled.
Under the assumption that we'll get udev events for *at least* all
partitions we care about (but possibly more) we can fix the race
entirely with one more fix coming in a later commit: if we make sure
that a loopback block device has zero kernel partitions when we take
possession of it, it doesn't matter anymore if we get spurious udev
events from a previous use. All we have to do is notice when the devices
we need all popped up.
Yu Watanabe