The method call already does a PK check, it was just forgotten to
allowlist this in the dbus policy. And in the dbus vtable for
OpenMachinePTY() call. (It was allowlisted in the per-machine
vtable…)
Anyway, clean this up.
Explain what we mean by "payload", and for which RR types this is
intended.
And don#t claim we'd output a full packet, because we don't. We output
only the RR in binary.
Fixes: #37737
We nowadays expose pidfdid at various places, e.g. envvars
and dbus properties. Also the sd_notify() MAINPID= message
has been complemented with MAINPIDFDID=. But acquiring
pidfdid is actually non-trivial especially considering
the 32-bit case, hence let's introduce a public helper
in sd-daemon specifically for that purpose.
systemd-pcrlock requires support for the PolicyAuthorizeNV command,
which is not implemented in the first TPM2 releases. We also strictly
require SHA-256 support. Hence add a tool for checking for both of
these.
This is a tighter version of "systemd-analyze has-tpm2", that checks for
the precise feature that systemd-pcrlock needs, on top of basic TPM2
functionality.
Fixes: #37607
A new core_pattern specifier was added, %F, to provide a PIDFD
to the usermode helper process referring to the crashed process.
This removes all possible race conditions, ensuring only the
crashed process gets inspected by systemd-coredump.
The kernel provides %d which is documented as
"dump mode—same as value returned by prctl(2) PR_GET_DUMPABLE".
We already query /proc/pid/auxv for this information, but unfortunately this
check is subject to a race, because the crashed process may be replaced by an
attacker before we read this data, for example replacing a SUID process that
was killed by a signal with another process that is not SUID, tricking us into
making the coredump of the original process readable by the attacker.
With this patch, we effectively add one more check to the list of conditions
that need be satisfied if we are to make the coredump accessible to the user.
Reportedy-by: Qualys Security Advisory <qsa@qualys.com>
In principle, %d might return a value other than 0, 1, or 2 in the future.
Thus, we accept those, but emit a notice.
We have already exposed device ID in the output of device ID in J
fields. Also sd_device_get_device_id() and sd_device_new_from_device_id()
are already public. Hence, making udevadm accept device IDs may be
useful.
With this change, as we save several data in /run/udev with device ID,
we can call udevadm something like the following:
```
udevadm info $(ls /run/udev/tags/uaccess)
```
Then, we can show all devices that has uaccess tag.
Add endpoint for listing boots. Output format mimics `journalctl
--list-boots -o json`, so it's a plain array containing index, boot ID
and timestamps of the first and last entry. Initial implementation
returns boots ordered starting with the current one and doesn't allow
any filtering (i.e. equivalent of --lines argument).
Fixes: #37573
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