| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The free function specified in the macro may be provided by a
dynamically loaded library.
Replaces #25781.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When we dissect images automatically, let's be a bit more conservative
with the file system types we are willing to mount: only mount common
file systems automatically.
Explicit mounts requested by admins should always be OK, but when we do
automatic mounts, let's not permit barely maintained, possibly legacy
file systems.
The list for now covers the four common writable and two common
read-only file systems. Sooner or later we might want to add more to the
list.
Also, it might make sense to eventually make this configurable via the
image dissection policy logic.
|
|\ \ \
| |_|/
|/| | |
string-util: don't add `const` to return pointer of empty_to_null() if input didn't have it
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
This changes the definition from enpty_to_null() so that we are still
typesafe (i.e. only accept strings) but do not drop (or add) any const
to the returned string that wasn't also on the input.
Inspired by: https://github.com/systemd/systemd/pull/25805/commits/3196e2996f613a2e3568a791c503306b7c58d593
|
| |
| |
| |
| |
| |
| |
| |
| | |
Even if root= is not specified on the kernel cmdline, we should honour
the other rootXYZ= options.
Fixes: #8411
See: #17034
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The MSI Summit E16 Flip A12UCT laptop sends the following unmapped
atkbd scancodes:
0x91: Launch MSI Control Center
0xf1: Toggle mic mute
0xf2: Rotate screen
The 0x91, 0xf1 and 0xf2 codes are already present in the MSI Prestige/Modern
series specific keymappings and the 0xf1 mapping is also already present in
the MSI Bravo 15-B5DX FnKeys entry.
This shows that these are generic to many MSI models, so add mappings for
these to the generic MSI mappings.
Since the MSI Bravo 15-B5DX FnKeys entry only contains the 0xf1 mapping and
that is covered by the generic MSI mappings now, that entry is removed.
Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/822
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216824
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The [kernel documentation][0] for the in_proximity_nearlevel sysfs
attribute on iio proximity devices states:
If the value read from the sensor is above or equal to the value in
this file an object should typically be considered near.
Meaning a 'greater than or equal to' comparison.
Make the documentation comment in 60-sensors.hwdb suggest a
greater-or-equal rather than a strict greater-than comparison.
[0]: https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-iio-proximity
Fixes #25793
|
| | |
|
| |
| |
| |
| |
| |
| | |
Fixes a bug introduced by 953c928c24455744d5534679998d129b947a5e04.
Fixes #25811.
|
| |
| |
| | |
Closes #25806.
|
| | |
|
|\ \
| | |
| | | |
tree-wide: use -EBADF more
|
| | | |
|
| | | |
|
| |/ |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
CVE-2022-4415: systemd: coredump not respecting fs.suid_dumpable kernel setting
Affects systemd >= 247 with libacl support enabled.
This is a merge of https://github.com/systemd/systemd-security/pull/12/.
I'm doing the merge locally because github doesn't support merging directly
from systemd/systemd-security to systemd/systemd.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
uid/gid/capabilities
When the user starts a program which elevates its permissions via setuid,
setgid, or capabilities set on the file, it may access additional information
which would then be visible in the coredump. We shouldn't make the the coredump
visible to the user in such cases.
Reported-by: Matthias Gerstner <mgerstner@suse.de>
This reads the /proc/<pid>/auxv file and attaches it to the process metadata as
PROC_AUXV. Before the coredump is submitted, it is parsed and if either
at_secure was set (which the kernel will do for processes that are setuid,
setgid, or setcap), or if the effective uid/gid don't match uid/gid, the file
is not made accessible to the user. If we can't access this data, we assume the
file should not be made accessible either. In principle we could also access
the auxv data from a note in the core file, but that is much more complex and
it seems better to use the stand-alone file that is provided by the kernel.
Attaching auxv is both convient for this patch (because this way it's passed
between the stages along with other fields), but I think it makes sense to save
it in general.
We use the information early in the core file to figure out if the program was
32-bit or 64-bit and its endianness. This way we don't need heuristics to guess
whether the format of the auxv structure. This test might reject some cases on
fringe architecutes. But the impact would be limited: we just won't grant the
user permissions to view the coredump file. If people report that we're missing
some cases, we can always enhance this to support more architectures.
I tested auxv parsing on amd64, 32-bit program on amd64, arm64, arm32, and
ppc64el, but not the whole coredump handling.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously 'systemctl edit' would only operate on
'override.conf', but users may need more than that.
Thus the new option '--drop-in' is added to allow
users to specify the drop-in file name.
Closes #25767
|
| |/
|/| |
|
|\ \
| | |
| | | |
Use -EBADF for fd initialization
|
| | |
| | |
| | |
| | |
| | | |
Having two blocks of normal variable declarations was unnecessary.
Also 'i' can be narrower in scope.
|
| | |
| | |
| | |
| | | |
In some places, initialization is dropped when unnecesary.
|
| | |
| | |
| | |
| | |
| | | |
Those fds never were, so it's not fair to say that they are in "bad state".
Let's use the shorter and more direct errno.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
-1 was used everywhere, but -EBADF or -EBADFD started being used in various
places. Let's make things consistent in the new style.
Note that there are two candidates:
EBADF 9 Bad file descriptor
EBADFD 77 File descriptor in bad state
Since we're initializating the fd, we're just assigning a value that means
"no fd yet", so it's just a bad file descriptor, and the first errno fits
better. If instead we had a valid file descriptor that became invalid because
of some operation or state change, the other errno would fit better.
In some places, initialization is dropped if unnecessary.
|
| | |
| | |
| | |
| | |
| | | |
We treat any negative value as "invalid fd", but signalfd only
accepts -1.
|
| | | |
|
|\ \ \
| | | |
| | | | |
units: allow systemd-userdbd to change process name
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
rename_process() requires CAP_SYS_RESOURCE so let's make sure it is in
our permitted set after execve() by adding in to the bounding set.
Previously,
systemd-userdbd.service - User Database Manager
Loaded: loaded (/usr/lib/systemd/system/systemd-userdbd.service; indirect; preset: disabled)
Active: active (running) since Mon 2022-12-19 17:07:21 CET; 17min ago
TriggeredBy: ● systemd-userdbd.socket
Docs: man:systemd-userdbd.service(8)
Main PID: 1880 (systemd-userdbd)
Status: "Processing requests..."
Tasks: 4 (limit: 2272)
Memory: 5.2M
CPU: 244ms
CGroup: /system.slice/systemd-userdbd.service
├─1880 /usr/lib/systemd/systemd-userdbd
├─2270 systemd-userwork
├─2271 systemd-userwork
└─2272 systemd-userwork
Now,
Loaded: loaded (/usr/lib/systemd/system/systemd-userdbd.service; indirect; preset: disabled)
Active: active (running) since Mon 2022-12-19 17:27:02 CET; 15s ago
TriggeredBy: ● systemd-userdbd.socket
Docs: man:systemd-userdbd.service(8)
Main PID: 2404 (systemd-userdbd)
Status: "Processing requests..."
Tasks: 4 (limit: 2272)
Memory: 5.5M
CPU: 89ms
CGroup: /system.slice/systemd-userdbd.service
├─2404 /usr/lib/systemd/systemd-userdbd
├─2407 "systemd-userwork: waiting..."
├─2408 "systemd-userwork: waiting..."
└─2409 "systemd-userwork: waiting..."
|
| |/ /
| | |
| | |
| | |
| | |
| | | |
Process renaming happens very seldomly so we are able to afford proper
permission check, i.e. actually check for CAP_SYS_RESOURCE capability
instead of euid.
|
| | |
| | |
| | | |
Closes #25782.
|
|\ \ \
| | | |
| | | | |
Trivial cleanups
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Coverity complains that the check is suspicious. Add a comment to help
the reader.
|
| | | |
| | | |
| | | |
| | | | |
'r' should only be used as in 'int r'.
|
| | | | |
|
| | | | |
|
|\ \ \ \
| |_|/ /
|/| | | |
p11kit: switch to dlopen()
|
| | | | |
|
|/ / / |
|
|\ \ \
| | | |
| | | | |
bootctl: split up bootctl.c into multiple files
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ / |
|
|/ /
| |
| |
| | |
For consistency with src/core/unit.c.
|
|\ \
| | |
| | | |
journal-remote: follow-ups for #25076
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Follow-up for f12b399dd6362a03379cb769954ebfb9972236ed from
https://github.com/systemd/systemd/pull/25076
CID#1501550
|