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.
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
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.
Zbigniew Jędrzejewski-Szmek
Shubhendra Kushwaha
Luca Boccassi
Jan Čermák
Lennart Poettering
Allison Karlitskaya
Stefan Herbrechtsmeier
TheHillBright
Luca Boccassi
Alberto Planas
maia x.
Yu Watanabe
Mike Yuan
Igor Opaniuk
Jörg Behrmann