Let's give the user control on how to handle JSON "null" assignments of
the log level. As one of three cases: as failure, as LOG_NULL (i.e. to
turn off logging) or as LOG_INFO (as our usual default log level).
Let's then use that in the generic SetLogLevel() call, so that callers
can use it to explicitly turn off logging in a service.
Note that this was (probably accidentally) already implemented, except
that the introspection enforcement blocked it. Let's clean this up and
make this officially a thing, since it's generally useful to turn off
logging I think.
Often we want to fork off a process that just hangs until we kill it,
let's add a simple flag to create one of this type, and use it at
various places.
Fixes the following error:
```
../src/basic/random-util.c: In function "fallback_random_bytes":
../src/basic/random-util.c:45:26: error: initializer-string for array of "char" is too long [-Werror=unterminated-string-initialization]
45 | .label = "systemd fallback random bytes v1",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
```
Unfortunately kernel reports EOF if there's an inconsistency between efivarfs var list
and what's actually stored in firmware, c.f. #34304. A zero size env var is not allowed in
efi and hence the variable doesn't really exist in the backing store as long as it is zero
sized, and the kernel calls this "uncommitted". Hence we translate EOF back to ENOENT here,
as with kernel behavior before
https://github.com/torvalds/linux/commit/3fab70c165795431f00ddf9be8b84ddd07bd1f8f
If the kernel changes behaviour (to flush dentries on resume), we can drop
this at some point in the future. But note that the commit is 11
years old at this point so we'll need to deal with the current behaviour for
a long time.
Fix#34304.
in strv_new() we have STRV_IGNORE for skipping over an argument in the
argument list. Let's add the same to strextend_with_separator():
strextend_with_separator(&x, "foo", POINTER_MAX, "bar");
will result in "foobar" being appended to "x". (POINTER_MAX Which is
different from NULL, which terminates the argument list).
This is useful for ternary op situations.
(We should probably get rid of STRV_IGNORE and just use POINTER_MAX
everywhere directly, but that's for another time.)
The functions are very similar, let's make them the same. If the first
argument to strextend() is NULL instead of extending a string we'll
allocate a fresh one and return that.
Background: Fedora/RHEL are switching to sysusers.d metadata for
creation of users and groups for system users defined by packages
(https://fedoraproject.org/wiki/Changes/RPMSuportForSystemdSysusers).
Packages carry sysusers files. During package installation, rpm calls an
program to execute on this config. This program may either be
/usr/lib/rpm/sysusers.sh which calls useradd/groupadd, or
/usr/bin/systemd-sysusers. To match the functionality provided by
useradd/groupadd from the shadow-utils project, systemd-sysusers must
emit audit events so that it provides a drop-in replacement.
systemd-sysuers will emit audit events AUDIT_ADD_USER/AUDIT_ADD_GROUP
when adding users and groups. The operation "names" are copied from
shadow-utils, so the format of the events that is generated on success
should be identical. On failure, things are more complicated. We write
the whole file at once, once, so we first generate "success" messages
for each entry, then we try to write the files, and if things fail, we
generate failure messages to all entries that we failed to write.
Background: Fedora/RHEL are switching to sysusers.d metadata for creation of
users and groups for system users defined by packages
(https://fedoraproject.org/wiki/Changes/RPMSuportForSystemdSysusers).
Packages carry sysusers files. During package installation, rpm calls an
program to execute on this config. This program may either be
/usr/lib/rpm/sysusers.sh which calls useradd/groupadd, or
/usr/bin/systemd-sysusers. To match the functionality provided by
useradd/groupadd from the shadow-utils project, systemd-sysusers must emit
audit events so that it provides a drop-in replacement.
systemd-sysuers will emit audit events AUDIT_ADD_USER/AUDIT_ADD_GROUP when
adding users and groups. The operation "names" are copied from shadow-utils in
Fedora (which has a patch to change them from the upstream version), so the
format of the events that is generated on success should be identical.
The helper code is shared between sysusers and utmp-wtmp. I changed the
audit_fd variable to be unconditional. This way we can avoid ugly iffdefery
every time the variable would be used. The cost is that 4 bytes of unused
storage might be present. This is negligible, and the compiler might even be
able to optimize that away if it inlines things.
The arm confidential compute architecture (CCA) provides a platform design for
confidential VMs running in a new realm context.
This can be detected by the existence of a platform device exported for the
arm-cca-guest driver, which provides attestation services via the realm
services interface (RSI) to the Realm Management Monitor (RMM).
Like the other methods systemd uses to detect Confidential VM's, checking
the sysfs entry suggests that this is a confidential VM and should only be
used for informative purposes, or to trigger further attestation.
Like the s390 detection logic, the sysfs path being checked is not labeled
as ABI, and may change in the future. It was chosen because its
directly tied to the kernel's detection of the realm service interface rather
to the Trusted Security Module (TSM) which is what is being triggered by the
device entry. The TSM module has a provider string of 'arm-cca-guest' which
could also be used, but that (IMHO) doesn't currently provide any additional
benefit except that it can fail of the module isn't loaded.
More information can be found here:
https://developer.arm.com/documentation/den0125/0300
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
(This is useful for the test case added in the next commit, where it's
kinda nice being able to use pidref_safe_fork_full() and acquiring a
pidref of the child in the child in one go. There's no other value in
this than a bit of synctactic sugar for that test. But otoh thre's no
good reason to prohibit FORK_WAIT use like this, hence either way, this
commit should be a good thing.)
This is establish the basic concepts for #35685, in the hope to get this
merged first.
This defines a special, fixed 64K UID range that is supposed to be used
by directory container images on disk, that is mapped to a dynamic UID
range at runtime (via idmapped mounts).
This enables a world where each container can run with a dynamic UID
range, but this in no way leaks onto the disk, thus making supposedly
dynamic, transient UID range assignments persistent.
This is infrastructure later used for the primary part of #35685: unpriv
container execution with directory images inside user's home dirs, that
are assigned to this special "foreign UID range".
This PR only defines the ranges, synthesizes NSS records for them via
userdb, and then exposes them in a new "systemd-dissect --shift" command
that can re-chown a container directory tree into this range (and in
fact any range).
This comes with docs. But no tests. There are tests in #35685 that cover
all this, but they are more comprehensive and also test nspawn's hook-up
with this, hence are excluded from this PR.