The man page pam_setcred(3) states:
> The credentials should be deleted after the session has been closed
> (with pam_close_session(3)).
Follow-up for 3bb39ea936.
Previously, unit_{start,stop,reload} would call the low-level cgroup
unfreeze function whenever a unit was started, stopped, or reloaded. It
did so with no error checking. This call would ultimately recurse up the
cgroup tree, and unfreeze all the parent cgroups of the unit, unless an
error occurred (in which case I have no idea what would happen...)
After the freeze/thaw rework in a previous commit, this can no longer
work. If we recursively thaw the parent cgroups of the unit, there may
be sibling units marked as PARENT_FROZEN which will no longer actually
have frozen parents. Fixing this is a lot more complicated than simply
disallowing start/stop/reload on a frozen unit
Fixes https://github.com/systemd/systemd/issues/15849
This commit overhauls the way freeze/thaw works recursively:
First, it introduces new FreezerActions that are like the existing
FREEZE and THAW but indicate that the action was initiated by a parent
unit. We also refactored the code to pass these FreezerActions through
the whole call stack so that we can make use of them. FreezerState was
extended similarly, to be able to differentiate between a unit that's
frozen manually and a unit that's frozen because a parent is frozen.
Next, slices were changed to check recursively that all their child
units can be frozen before it attempts to freeze them. This is different
from the previous behavior, that would just check if the unit's type
supported freezing at all. This cleans up the code, and also ensures
that the behavior of slices corresponds to the unit's actual ability
to be frozen
Next, we make it so that if you FREEZE a slice, it'll PARENT_FREEZE
all of its children. Similarly, if you THAW a slice it will PARENT_THAW
its children.
Finally, we use the new states available to us to refactor the code
that actually does the cgroup freezing. The code now looks at the unit's
existing freezer state and the action being requested, and decides what
next state is most appropriate. Then it puts the unit in that state.
For instance, a RUNNING unit with a request to PARENT_FREEZE will
put the unit into the PARENT_FREEZING state. As another example, a
FROZEN unit who's parent is also FROZEN will transition to
PARENT_FROZEN in response to a request to THAW.
Fixes https://github.com/systemd/systemd/issues/30640
Fixes https://github.com/systemd/systemd/issues/15850
So far credentials are a concept for system services only: to encrypt or
decrypt credential you must be privileged, as only then you can access
the TPM and the host key.
Let's break this up a bit: let's add a "user-scoped" credential, that
are specific to users. Internally this works by adding another step to
the acquisition of the symmetric encryption key for the credential: if a
"user-scoped" credential is used we'll generate an symmetric encryption
key K as usual, but then we'll use it to calculate
K' = HMAC(K, flags || uid || machine-id || username)
and then use the resulting K' as encryption key instead. This basically
includes the (public) user's identity in the encryption key, ensuring
that only if the right user credentials are specified the correct key
can be acquired.
This file is a bit misnamed. What it actually implements is one specific
BPF LSM module, that restricts file systems. As such it really should be
named after that, and not primarily by the mechanism it uses for that.
With this our glue code is now named the same way as the actual bpf code
files in src/core/bpf/, thus things become a bit more symmetric.
This is particular relevant as we'll soon have another BPF LSM in our
tree, see #26826, and we should be able to distinguish them by name.
This commit just renames the files and does some dumb search/replace of
the string. A follow-up commit will name some functions more expressively
inside the files.
We can only delegate actual controllers, not the BPF pseudo-controllers
we defined as there's imply no concept for that. Hence, when users set
Delegate=yes to do a wildcard delegation, only delegate the regular
controllers.
This means that we won't bother with BPF stuff for such units where it's
entirelly unnecessary.
Log about missing executor at the emergency level, so the message always
makes it to the console - otherwise it won't get anywhere, since we
can't even start systemd-journald in that case.
Before:
Welcome to Arch Linux!
[ 5.202479] systemd[1]: Failed to allocate manager object: No such file or directory
[!!!!!!] Failed to allocate manager object.
[ 5.207741] systemd[1]: Freezing execution.
After:
Welcome to Arch Linux!
[ 5.279408] systemd[1]: Failed to open executor binary '/usr/lib/systemd/systemd-executor': No such file or directory
[ 5.290756] systemd[1]: Failed to allocate manager object: No such file or directory
[!!!!!!] Failed to allocate manager object.
[ 5.295919] systemd[1]: Freezing execution.
These are wrappers around getpwuid_r() and friends, and will allocate the
right-sized buffer for this call.
We so far had multiple implementations of a buffer allocation loop
around getpwuid_r() and friends, and they all suck in some way. Let's
clean this up and add a common implementation, and use it everywhere.
Also, be more careful with error numbers, in particular systematically
turn ENOENT into ENOSRCH (the former is what is returned if /etc/passwd
is absent, which we want to consider identical to user not existing,
which is ENOSRCH). We so far did this at some invocations, but not all.
There are some invocations of getpwuid() left in the codebase. We really
should fix those too, and have a single unified implementation of the
logic, but those are not as trivial to convert, so left for another
time.
Previously, path units would remain in the running state while their
target unit is deactivating. This left a window of time where the target
unit is no longer operational (i.e. it is busy deactivating/cleaning
up/etc) but the path unit would continue to ignore inotify events. In
short: any inotify event that occurs while the target unit deactivates
would be completely lost.
With this commit, the path will go back into a waiting state when the
target unit starts deactivating. This means that any inotify event that
occurs while the target unit deactivates will queue a start job.
Let's put the run queue really the last spot, as we should only start
doing more work if we really have nothing else to do anymore.
Let's move the service watchdog after the rewatch PID logic for similar
logic: it will possibly result in new jobs being enqueued to stop
things, and we should really have done all other work first.
We want to make sure we don't confuse the case "process started
successfully but then failed quickly" from the case "process failed to
start". Hence we need to make sure we take notice of Type=exec before we
bother with SIGCHLD.
Hence move EVENT_PRIORITY_EXEC_FD to the front. In fact, let's move it
even further up than SIGCHLD, i.e. before sd_notify() handling, so that
we don't end up processing service state change notifications before we
even considered that the service is properly started.
This also gives the cgroup OOM handling and the exec_fd handling
different priorities, to improve robustness of the system, we should act
quickly on OOM, and it doesn't matter if a service started succcessfully
if we have to act on OOM anyway.
This is based on Andrew Onyshchuk <andryk.rv@gmail.com> work here:
See: #30799Fixes: #28304
It's hard to oversee the assigned processing priorities of the various
event sources we have. Let's unify them in a table (an enum), where we
can have a single consisten look at them, and then reference the table
entries by expressive symbols.
This doesn#t change behaviour in any way, it just gives each priority a
nice label, but doesn't change any of the priorities.
Prompted by: #30799
Mike Yuan
Yu Watanabe
Luca Boccassi
Lennart Poettering
Adrian Vovk
Michal Koutný
Frantisek Sumsal