A "string" is a concept in C. In a text-based API, this is implicit, especially
if we say that something was "formatted". So change occurences of "decimal
string" to just "decimal". Similarly, "numerics" is unclear, say "digits".
Also, a "timestamp is in a clock" just sounds wrong. Reword those sentences.
When populating a filesytem with CopyFiles=, we first copy the files to
a temporary directory. Make sure we use the (new) COPY_FS_VERITY flag
when doing that copy so that the `mkfs` that we invoke can see the files
with fs-verity enabled.
Closes#35352
We currently pass the CopyFlags that we use to populate the temporary
directory in the form of a constant at each of the copy_tree_at() call
sites. De-duplicate that and move it into the `CopyFilesLine` struct,
initializing it from the parser.
Add our first non-constant flag: `fsverity=`. This can be set to `off`
(the default) or `copy`, in which case we copy the fs-verity state from
the source files.
This arrangement is amenable to the introduction of more flags to
`CopyFiles=` lines, if we want to add them in the future.
Update the `repart.d(5)` manpage.
Closes#35352
Signed-off-by: Allison Karlitskaya <allison.karlitskaya@redhat.com>
Add support for the hardware version. The version describes a distinct
version of compatibility hardware. The value is read from the file
/etc/machine-info or DMI as fallback.
The integration provides an unified interface to collect detail hardware
information. The /etc/machine-info entry enables embedded devices
without UEFI support to read the information from a custom store.
Add support for the hardware Stock-Keeping Unit (SKU). The SKU describes
a distinct type of hardware for sale, purchase or inventory management.
The value is read from the file /etc/machine-info or DMI as fallback.
The integration provides an unified interface to collect detail hardware
information. The /etc/machine-info entry enables embedded devices
without UEFI support to read the information from a custom store.
We generally frown on config options that are called
EnableXYZ=/DisableXYZ=, hence drop this here too. Note that the original
sin was that the pre-existing D-Bus property already used the prefix.
But given that D-Bus properties are substantially more low-level (i.e.
developer focused) than the config knobs, let's bite the bullet and
name the configuration option cleanly, even if the dbus property carries
the damn prefix.
The knob was added post v257, hence this is not a compat break.
Follow-up for: 130698dc20
The old description makes users wrongly assume that the cap of 4G
applied, even when the user specifies a value that will result in higher
than 4G. This commit avoids this misunderstanding.
This permits configuration of additional "delegates" which ensure that
lookups for certain DNS zones are routed to specific sets of DNS
servers, in addition to the routes we create for each network interface.
For now, this allows only static configuration, but eventually we should
open this up to IPC.
Fixes: #5573#14159#20485#21260#24532#32022
(Fixes#32022, because now redundant)
If --generate-fstab=PATH is used, there is the possibility that the
fstab file already exists, making systemd-repart fail.
This commit will add a new --append-fstab= parameter, that will read
the file and merge it with the new generated content. Using the
comments, the command can separate the automatic-generated section from
the user-provided section, allowing for the next append the replacement
only of the automatic-generated section, keeping the user one.
`ExtensionImages=` and `ExtensionDirectories=` now let you specify
vpick-named extensions; however, since they just get set up once when
the service is started, you can't see newer versions without restarting
the service entirely. Here, also reload confext extensions when you
reload a service. This allows you to deploy a new version of some
configuration and have it picked up at reload time without interruption
to your workload.
Right now, we would only reload confext extensions and leave the sysext
ones behind, since it didn't seem prudent to swap out what is likely
program code at reload. This is made possible by only going for the
`SYSTEMD_CONFEXT_HIERARCHIES` overlays (which only contains `/etc`).
This PR:
- Adjusts `service.c` to also refresh extensions when needed.
- Adds integration tests to check that a confext reload actually
occurred.
- Adds to the `systemd.exec` man pages to document this behavior.
This is a follow up to #24864 and #31364. Thank you to @bluca and
@goenkam for help in getting this up.
If --generate-fstab=PATH is used, there is the possibility that the
fstab file already exists, making systemd-repart fail.
This commit will add a new --append-fstab= parameter, that will read
the file and merge it with the new generated content. Using the
comments, the command can separate the automatic-generated section from
the user-provided section, allowing for the next append the replacement
only of the automatic-generated section, keeping the user one.
Signed-off-by: Alberto Planas <aplanas@suse.com>
Accept=yes has very valid usecases (i.e. for sporadically invoked
services) and strong benefits (i.e. better security because connections
can be sandboxed nicely, isolating them). Let's hence reword things and
stop claiming that Accept=yes was a legacy thing, because it really
isn't.
Some other man fixes, too
Our baseline is v5.4 and cgroup v2 is enforced now,
which means CPU accounting is cheap everywhere without
requiring any controller, hence just remove the directive.
This returns to the original approach proposed in
https://github.com/systemd/systemd/pull/17270. After review, the approach was
changed to use sd_pid_get_owner_uid() instead. Back then, when running in a
typical graphical session, sd_pid_get_owner_uid() would usually return the user
UID, and when running under sudo, geteuid() would return 0, so we'd trigger the
secure path.
sudo may allocate a new session if is invoked outside of a session (depending
on the PAM config). Since nowadays desktop environments usually start the user
shell through user units, the typical shell in a terminal emulator is not part
of a session, and when sudo is invoked, a new session is allocated, and
sd_pid_get_owner_uid() returns 0 too. Technically, the code still works as
documented in the man page, but in the common case, it doesn't do the expected
thing.
$ build/test-sd-login |& rg 'get_(owner_uid|cgroup|session)'
sd_pid_get_session(0) → No data available
sd_pid_get_owner_uid(0) → 1000
sd_pid_get_cgroup(0) → /user.slice/user-1000.slice/user@1000.service/app.slice/app-ghostty-transient-5088.scope/surfaces/556FAF50BA40.scope
$ sudo build/test-sd-login |& rg 'get_(owner_uid|cgroup|session)'
sd_pid_get_session(0) → c289
sd_pid_get_owner_uid(0) → 0
sd_pid_get_cgroup(0) → /user.slice/user-0.slice/session-c289.scope
I think it's worth checking for sudo because it is a common case used by users.
There obviously are other mechanims, so the man page is extended to say that
only some common mechanisms are supported, and to (again) recommend setting
SYSTEMD_LESSSECURE explicitly. The other option would be to set "secure mode"
by default. But this would create an inconvenience for users doing the right
thing, running systemctl and other tools directly, because then they can't run
privileged commands from the pager, e.g. to save the output to a file. (Or the
user would need to explicitly set SYSTEMD_LESSSECURE. One option would be to
set it always in the environment and to rely on sudo and other tools stripping
it from the environment before running privileged code. But that is also fairly
fragile and it obviously relies on the user doing a complicated setup to
support a fairly common use case. I think this decreases usability of the
system quite a bit. I don't think we should build solutions that work in
priniciple, but are painfully inconvenient in common cases.)
Fixes https://yeswehack.com/vulnerability-center/reports/346802.
Also see https://github.com/polkit-org/polkit/pull/562, which adds support for
$SUDO_UID/$SUDO_GID to pkexec.
Let's optionally issue a Varlink Synchronize() call in --follow mode
when asked to terminate. This is useful so that the tool can be called
and it is guaranteed it processed all messages generated before the
request to exit before it exits.
We want this in "systemd-run -v" in particular, so that we can be sure
we are not missing any log output from the invoked service before it
exits
Allow callers to synchronize on the point in time where the journal file
watches are fully established, in --follow mode.
Tools can invoke journalctl using this, knowing that any log message
happening after the READY=1 is definitely going to be processed by the
journalctl invocation.
Add support for a sysfail boot entry. Sysfail boot entries can be used
for optional tweaking the automatic selection order in case a failure
state of the system in some form is detected (boot firmware failure
etc).
The EFI variable `LoaderEntrySysFail` contains the sysfail boot loader
entry to use. It can be set using bootctl:
```
$ bootctl set-sysfail sysfail.conf
```
The `LoaderEntrySysFail` EFI variable would be unset automatically
during next boot by `systemd-boot-clear-sysfail.service` if no system
failure occured, otherwise it would be kept as it is and a system
failure reason will be saved to `LoaderSysFailReason` EFI variable.
`sysfail_check()` expected to be extented to support possibleconditions
when we should boot sysfail("recovery") boot entry.
Also add support for using a sysfail boot entry in case of UEFI firmware
capsule update failure [1]. The status of a firmware update is obtained
from the EFI System Resource Table (ESRT), which provides an optional
mechanism for identifying device and system firmware resources for the
purposes of targeting firmware updates to those resources.
Current implementation uses the value of LastAttemptStatus field from
ESRT, which describes the result of the last firmware update attempt for
the firmware resource entry. The field is updated each time an
`UpdateCapsule()` is attempted for an ESRT entry and is preserved across
reboots (non-volatile).
This can be be used in setups with support for A/B OTA updates, where
the boot firmware and Linux/RootFS might be updated synchronously.
The check is activated by adding "sysfail-firmware-upd" to loader.conf
[1]
https://uefi.org/specs/UEFI/2.10/23_Firmware_Update_and_Reporting.html