This adds the same sections we already have in the homectl --help blurb
also to the man page.
While we are at it, let's also add a new section for Authentication
related switches.
There's finally quota on tmpfs, hence let's use it to make it harder for
users to DoS the system by consuming all disk space in /tmp/ and
/dev/shm/.
This enforces a default limit of 80% quota of the backing fs for these
two dirs for users, but this can be overriden in the user record, if
desired.
This also adds two other interesting features:
1. mount units gain GracefulOptions= which takes optional mount options
that are added only if supported by the kernel. (this is used to enable
usrquota on /tmp/, if available.)
2. The PAM logic in service management now supports reading passwords
from service credentials and via the askpw logic. This used for make
testing easy (so that we can run0 into a homed user which strictly
requires a password).
So far nspawn supported unpriv containers only if backed by a DDI. This
adds dir-based unpriv containers too.
To make this work this introduces a new UID concept to systemd: the
"foreign UID range". This is a high UID range of size 64K. The idea is
that disk images that are "foreign" to the local system can use that,
and when a container or similar is invoked from it, a transiently
allocated dynamic UID range is mapped from that foreign UID range via id
mapped mounts.
This means the fully dynamic, transient UID ranges never hit the disk,
which should vastly simplify management, and does not require that uid
"subranges" are persistently delegated to any users.
The mountfsd daemon gained a new method call for acquiring an idmapped
mount fd for an mount tree owned by the foreign UID range. Access is
permitted to unpriv clients – as long as the referenced inode is located
within a dir owned by client's own uid range.
Enforce the quota on these two tmpfs at the same place where we mount
the per-user $XDG_RUNTIME_DIR. Conceptually these are very similar
concepts, and it makes sure to enforce the limits at the same place with
the same lifecycle.
Also, when a filename is specified, also search udev rules file in
udev/rules.d directories.
This also refuses non-existing files, and file neither nor a regular
nor a directory, e.g. /dev/null.
The "vice versa" in the old text could be interpreted as either
(wrong) "stopping the former will start the latter", or
(right) "starting the latter will stop the former".
Rephrase to avoid that ambiguity.
systemctl has a --job-mode= argument, and adding the same argument to
systemd-run is useful for starting transient scopes with dependencies.
For example, if a transient scope BindsTo a service that is stopping,
specifying --job-mode=replace will wait for the service to stop before
starting it again, while the default job mode of "fail" will cause the
systemd-run invocation to fail.
systemctl has a --job-mode= argument, and adding the same argument to
systemd-run is useful for starting transient scopes with dependencies.
For example, if a transient scope BindsTo a service that is stopping,
specifying --job-mode=replace will wait for the service to stop before
starting it again, while the default job mode of "fail" will cause the
systemd-run invocation to fail.
This adds -D/--extra-rules-dir=DIR switch for 'udevadm test' command.
When specified, udev rules files in the specified directory will be also
loaded. This may be useful for debugging udev rules by copying some udev
rules files to a temporary directory.
Uses the newly added policy-digest verb of systemd-measure, for the same
purpose: build a UKI and get digests for the .pcrsig section out, so
that they can be offline signed and reattached
When doing offline signing we need to know the exact payload
to sign, and the 'calculate' verb doesn't really show that, it
shows the PCR values. But what we sign is the hash of the policy.
So add a new verb that outputs the json payload that goes in the
.pcrsig section, without the .sig object, so that we can take them
and give the .pol object to an offline and asynchronous signing
service, such as SUSE's Open Build Service, and then add the .sig
object to the json and attach it to a UKI.
This new setting can be used to specify mount options that shall only be
added to the mount option string if the kernel supports them.
This shall be used for adding "usrquota" to tmp.mount without breaking compat,
but is generally be useful.
This adds a new --lightweight=yes/no switch which allows controlling
whether the invoked service will have the service manager around or not.
Moreover, this changes that if the target user is root it will now
support to the lightweight mode, i.e. run0 towards root will no longer
pull in the service manager (a real tty login via getty still will
though!).
My thinking here is that quickly raising privileges via run0 probably
shouldn't be considered a proper login but just something short lived,
temporary for a single command or similar.
This new session class is to "user" what "background" is to
"background-light": it doesn't cause the per-user service manager to
start.
This new session class is now the default if no session class was
provided at session registration time and the following conditions hold:
1. The session is not graphical
2. The user is not a regular user (but not root)
Or in other words root and system users won't get a service manager
started automatically if they go through a PAM session as part of things
like cron or ftp. They will however still get one if they log in
graphically.
This changes behaviour a bit, but hopefully in OK was.
This also makes "background-light" for system users incl. root.
This addresses one of the ideas discussed in #34988.
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>
Let's clarify more explicitly that privileged calls to
systemd-notify --pid= and sd_pid_notify() effectively override any
configured NotifyAccess=main|exec for a service.
When copying a directory from or to an image, let's always merge
with existing directories instead of failing with "File Exists".
Fixes https://github.com/systemd/mkosi/issues/3342.
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.
pam_systemd is used to create logind sessions and to apply extended
attributes from json user records. Not every application that creates a
pam session expects a login scope, but may be interested in the extended
attributes of json user records. Session class "none" implements this
service by disabling logind for this session altogether.
---
Closes: #34988
This change adds a new firmware type device entry for the .hwids
section.
It also adds compile time validations and appropriate unit tests for
them.
chid_match() and related helpers have been updated accordingly.
Duplicate of https://github.com/systemd/systemd/pull/35281
Last review feedback's from this above PR has been incorporated and
merged.
@anonymix007
When running unprivileged containers, we run into a scenario where an
unpriv owned cgroup has a subcgroup delegated to another user (i.e. the
container's own UIDs). When the owner of that cgroup dies without
cleaning it up then the unpriv service manager might encounter a cgroup
it cannot delete anymore.
Let's address that: let's expose a method call on the service manager
(primarly in PID1) that can be used to delete a subcgroup of a unit one
owns. This would then allow the unpriv service manager to ask the priv
service manager to get rid of such a cgroup.
This commit only adds the method call, the next commit then adds the
code that makes use of this.
Lennart Poettering
Mike Yuan
Yu Watanabe
Andrew Sayers
Gavin Li
Luca Boccassi
Hendrik Wolff
nl6720
Jeremy Linton
Daan De Meyer
Sea-Eun Lee
Zbigniew Jędrzejewski-Szmek
