When booting with debug logs, we print:
Setting '/proc/sys/fs/file-max' to '9223372036854775807
'
Setting '/proc/sys/fs/nr_open' to '2147483640
'
Couldn't write fs.nr_open as 2147483640, halving it.
Setting '/proc/sys/fs/nr_open' to '1073741816
'
Successfully bumped fs.nr_open to 1073741816
The strange formatting is because we explicitly appended a newline in those two
places. It seems that the kernel doesn't care. In fact, we have a few dozen other
writes to sysctl where we don't append a newline. So let's just drop those here
too, to make the code a bit simpler and avoid strange output in the logs.
Curently, these two flags were implied by dissect_loop_device(), but
that's not right, because this means systemd-gpt-auto-generator will
dissect the root block device with these flags set and that's not
desirable: the generator should not cause the partition devices to be
created (we don't intend to use them right-away after all, but expect
udev to find/probe them first, and then mount them though .mount units).
And there's no point in opening the partition devices, since we do not
intend to mount them via fds either.
Hence, rework this: instead of implying the flags, specify them
explicitly.
While we are at it, let's also rename the flags to make them more
descriptive:
DISSECT_IMAGE_MANAGE_PARTITION_DEVICES becomes
DISSECT_IMAGE_ADD_PARTITION_DEVICES, since that's really all this does:
add the partition devices via BLKPG.
DISSECT_IMAGE_OPEN_PARTITION_DEVICES becomes
DISSECT_IMAGE_PIN_PARTITION_DEVICES, since we not only open the devices,
but keep the devices open continously (i.e. we "pin" them).
Also, drop the DISSECT_IMAGE_BLOCK_DEVICE combination flag, since it is
misleading, i.e. it suggests it was appropriate to specify on all
dissected blocking devices, but that's precisely not the case, see the
systemd-gpt-auto-generator case. My guess is that the confusion around
this was actually the cause for this bug we are addressing here.
Fixes: #25528
Currently, services use mount_move_root() in order to setup the root
directory of services using a mount namespace. This relies on MS_MOVE
and chroot(). However, this has serious drawbacks even for relatively
simple mount propagation scenarios.
What systemd currently does is roughly equivalent to the following shell
code:
unshare --mount --propagation=shared
cd /
mount --make-rslave /
mkdir /new-root
mount --rbind / /new-root
cd /new-root
mount --move /new-root /
chroot .
This looks simple enough but has the consequence that two separate mount
trees exist for the lifetime of the service. The first one was created
when the mount namespace was created, and the second one when a new
mount for the rootfs was created. The first mount tree sticks around as
a shadow mount tree. Both mount trees are dependent mounts with the host
rootfs as their dominating mount.
Now, when mount propagation is triggered by the host by e.g.,
mount --bind /opt /mnt
it means that two propagation events are generated. I'm skipping over
the exact kernel details as they aren't that important. The gist is that
for every propagation event that is generated a second one is generated
for the shadow mount tree. In other words, the kernel creates two copies
for each mount that is propagated instead of one.
This isn't necessary. We can simply change the sequence above to:
unshare --mount --propagation=shared
cd /
mount --make-rslave /
mkdir /new-root
# stash fd to old rootfs
# stash fd to new rootfs
mount --rbind / /new-root
mkdir /new-root
cd /new-root
pivot_root . .
# new root is tucked under old root
# chdir into old rootfs via stashed fd
umount -l /old-root
The pivot_root allows us to get rid of the old mount tree that was
created when the mount namespace was created. So after this sequence
only one mount tree is alive. Plus, it's safer and nicer. Moving mounts
isn't pleasnt.
This patch doesn't convert nspawn yet as the requirements are more
tricky given that it wants to preserve the rootfs as a shared mount
which goes against pivot_root() requirements.
Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
The compiler should recognize that these are constant expressions, but
let's better make this explicit, so that the linker can safely share the
initializations all over the place.
If we call raise(), we lose the information from the original signal.
If we use rt_sigqueueinfo(), the original siginfo gets reused which
is helpful when debugging crashes.
Rather than passing seeds up to userspace via EFI variables, pass seeds
directly to the kernel's EFI stub loader, via LINUX_EFI_RANDOM_SEED_TABLE_GUID.
EFI variables can potentially leak and suffer from forward secrecy
issues, and processing these with userspace means that they are
initialized much too late in boot to be useful. In contrast,
LINUX_EFI_RANDOM_SEED_TABLE_GUID uses EFI configuration tables, and so
is hidden from userspace entirely, and is parsed extremely early on by
the kernel, so that every single call to get_random_bytes() by the
kernel is seeded.
In order to do this properly, we use a bit more robust hashing scheme,
and make sure that each input is properly memzeroed out after use. The
scheme is:
key = HASH(LABEL || sizeof(input1) || input1 || ... || sizeof(inputN) || inputN)
new_disk_seed = HASH(key || 0)
seed_for_linux = HASH(key || 1)
The various inputs are:
- LINUX_EFI_RANDOM_SEED_TABLE_GUID from prior bootloaders
- 256 bits of seed from EFI's RNG
- The (immutable) system token, from its EFI variable
- The prior on-disk seed
- The UEFI monotonic counter
- A timestamp
This also adjusts the secure boot semantics, so that the operation is
only aborted if it's not possible to get random bytes from EFI's RNG or
a prior boot stage. With the proper hashing scheme, this should make
boot seeds safe even on secure boot.
There is currently a bug in Linux's EFI stub in which if the EFI stub
manages to generate random bytes on its own using EFI's RNG, it will
ignore what the bootloader passes. That's annoying, but it means that
either way, via systemd-boot or via EFI stub's mechanism, the RNG *does*
get initialized in a good safe way. And this bug is now fixed in the
efi.git tree, and will hopefully be backported to older kernels.
As the kernel recommends, the resultant seeds are 256 bits and are
allocated using pool memory of type EfiACPIReclaimMemory, so that it
gets freed at the right moment in boot.
The name "def.h" originates from before the rule of "no needless abbreviations"
was established. Let's rename the file to clarify that it contains a collection
of various semi-related constants.
I wanted to move saved_arg[cv] to process-util.c+h, but this causes problems:
process-util.h includes format-util.h which includes net/if.h, which conflicts
with linux/if.h. So we can't include process-util.h in some files.
But process-util.c is very long anyway, so it seems nice to create a new file.
rename_process(), invoked_as(), invoked_by_systemd(), and argv_looks_like_help()
which lived in process-util.c refer to saved_argc and saved_argv, so it seems
reasonable to move them to the new file too.
util.c is now empty, so it is removed. util.h remains.
I changed imports of util.h to initrd-util.h, or added an import of
initrd-util.h, to keep compilation working. It turns out that many files didn't
import util.h directly.
When viewing the patch, don't be confused by git rename detection logic:
a new .c file is added and two functions moved into it.
Many long-running services will reload configuration and therefore
credentials on reload. Therefore its useful if a service reload will
also update credentials.
Tested in https://github.com/numtide/systemd-vaultd/pull/12
Using fsopen()/fsconfig(), we can check if hidepid/subset are supported to
avoid the noisy logs from the kernel if they aren't supported. This works
on centos/redhat 8 as well since they've backported fsopen()/fsconfig().
Otherwise, if a device is removed while switching root, then the
corresponding .device unit will never go to inactive state.
This replaces the code dropped by cf1ac0cfe4.
Fixes#25106.
We treat symlinks to unit files outside of the search path differently from
symlinks to unit files *in* the search path. The former are "linked" unit
files, while the latter are enablement symlinks and such and will be removed
when disabling the unit.
The history of the check for in_search_path() is interesting: this condition
was added already in the first version of the code in
830964834f. Since the beginning, matching
arguments would simply be ignored. I think this is dubious. The man page says:
> Link a unit file that is *not* in the unit file search paths
> into the unit file search path
But for backwards-compat, let's continue to silently do nothing for files
*in* the search path.
The case of symlinks to unit files underneath the search path, but in some
subdirectory, is less clear. We didn't check for this case, so it was
implicitly allowed. But that's just an oversight, we don't want to allow people
to create additional subhierarchies under our hierarchy. Let's check for this
case and refuse.
Closes#24605.
This fix unfortunately introduced a much worse regression that
is affecting many users, so let's revert it for now and rework
it in the next release.
This reverts commit 5ded3917a1.
Fixes https://github.com/systemd/systemd/issues/24984
The precise bounds of the scheduling priority depend on the scheduling policy,
so depending on the order in which the two settings are specified the
validation might pass or fail.
When checking the setting only validate the outer range (valid values in general are 0 to 99),
and let the execution fail later if the priority does not match the
specified policy (1 to 99 for RR/FIFO, 0 for the rest).
Fixes https://github.com/systemd/systemd/issues/20320
Allow-listing a device implicitly blocks everything else, so this
has the opposite of the intended effect when PrivateDevices= is
not used.
Allow-list char-rtc only if there is a device policy set.
Fixes https://github.com/systemd/systemd/issues/18142
Use target process context to set socket context when using SELinuxContextFromNet
not systemd's context. Currently when using the SELinuxContextFromNet option for
a socket activated services, systemd calls getcon_raw which returns init_t and
uses the resulting context to compute the context to be passed to the
setsockcreatecon call. A socket of type init_t is created and listened on and
this means that SELinux policy cannot be written to control which processes
(SELinux types) can connect to the socket since the ref policy allows all
'types' to connect to sockets of the type init_t. When security accessors see
that any process can connect to a socket this raises serious concerns. I have
spoken with SELinux contributors in person and on the mailing list and the
consensus is that the best solution is to use the target executables context
when computing the sockets context in all cases.
[zjs review/comment:
This removes the branch that was added in 16115b0a7b.
16115b0a7b did two things: it had the branch here
in 'socket_determine_selinux_label()' and a code in 'exec_child()' to call
'label_get_child_mls_label(socket_fd, command->path, &label)'.
Before this patch, the flow was:
'''
mac_selinux_get_child_mls_label:
peercon = getpeercon_raw(socket_fd);
if (!exec_label)
exec_label = getfilecon_raw(exe);
socket_open_fds:
if (params->selinux_context_net) #
label = mac_selinux_get_our_label(); # this part is removed
else #
label = mac_selinux_get_create_label_from_exe(path);
socket_address_listen_in_cgroup(s, &p->address, label);
exec_child():
exec_context = mac_selinux_get_child_mls_label(fd, executable, context->selinux_context);
setexeccon(exec_context);
'''
]
(s) is just ugly with a vibe of DOS. In most cases just using the normal plural
form is more natural and gramatically correct.
There are some log_debug() statements left, and texts in foreign licenses or
headers. Those are not touched on purpose.
This function was returning 0 or 1 on success. It has many callers, and it
wasn't clear if any of them care about the distinction. It turns out they don't
and the return values were done for convenience because manager_load_unit_prepare()
returns 0 or 1. Let's invert the code in the static function to follow the usual
pattern where 0 means "no work was done" and 1 means "work was done", and make
the non-static function always return 0 to make the code easier to read, and
also add comments that explain what is happening.
No functional change.
In https://github.com/containers/podman/issues/16107, starting of a transient
slice unit fails because there's a "global" drop-in
/usr/lib/systemd/user/slice.d/10-oomd-per-slice-defaults.conf (provided by
systemd-oomd-defaults package to install some default oomd policy). This means
that the unit_is_pristine() check fails and starting of the unit is forbidden.
It seems pretty clear to me that dropins at any other level then the unit
should be ignored in this check: we now have multiple layers of drop-ins
(for each level of the cgroup path, and also "global" ones for a specific
unit type). If we install a "global" drop-in, we wouldn't be able to start
any transient units of that type, which seems undesired.
In principle we could reject dropins at the unit level, but I don't think that
is useful. The whole reason for drop-ins is that they are "add ons", and there
isn't any particular reason to disallow them for transient units. It would also
make things harder to implement and describe: one place for drop-ins is good,
but another is bad. (And as a corner case: for instanciated units, a drop-in
in the template would be acceptable, but a instance-specific drop-in bad?)
Thus, $subject.
While at it, adjust the message. All the conditions in unit_is_pristine()
essentially mean that it wasn't loaded (e.g. it might be in an error state),
and that it doesn't have a fragment path (now that drop-ins are acceptable).
If there's a job for it, it necessarilly must have been loaded. If it is
merged into another unit, it also was loaded and found to be an alias.
Based on the discussion in the bugs, it seems that the current message
is far from obvious ;)
Fixes https://github.com/containers/podman/issues/16107,
https://bugzilla.redhat.com/show_bug.cgi?id=2133792.
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Daan De Meyer
Mark Laws
Christian Brauner
Michal Sekletar
Yu Watanabe
Mike Yuan
Luca Boccassi
Pasha Vorobyev
Jason A. Donenfeld
Christian Göttsche
Jörg Thalheim
xiaoyang
Jacek Migacz
Ted X. Toth