| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Given that we already have the file descriptor opened for writing, it
would make sense to call fstatvfs with that file descriptor rather than
statvfs with the directory path that was used to open that descriptor.
|
| |
|
|
|
| |
Commit v250-767-ge677041e7a updated the built-in configuration, but
missed the accompanying documentation.
|
| |\
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
-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.
|
| |/
|
|
|
|
|
|
|
|
|
| |
In both cases, the json string is short, so we can print it, which is useful
for diagnosing invalid data in packages. But we need escape non-printable
characters.
https://bugzilla.redhat.com/show_bug.cgi?id=2152685
I went over the rest of the codebase, and it seems that other calls to
json_parse() don't have this problem.
|
| |
|
|
|
|
| |
The name "def.h" originates from before the rule of "no needless abbreviations"
was established. Let's rename the file to clarify that it contains a collection
of various semi-related constants.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
With this option, coredumpctl looks for journal files under the
specified root directory
|
| |
|
|
|
|
|
|
|
|
|
|
| |
All users were setting this to some static string (usually "-"), so let's
simplify things by not doing strdup, but instead limiting callers to a fixed
set of values. In preparation for the next commit, the function is renamed from
"empty" to "replacement", because it'll be used for more than empty fields. I
didn't do the whole string-table setup, because it's all used internally in one
file and this way we can immediately assert if an invalid value is passed in.
Some callers were (void)ing the error, others were ignoring it, and others
propagating. It's nicer to remove the boilerplate.
|
| |
|
|
| |
"Disk Size" could be mistaken for "Size of the Disk".
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, if journald coredumps, the coredump is written to
/var/lib/systemd/coredump but the coredump metadata is not written
to the journal meaning we can't find out about the coredump's
existence via the journal. This means that coredumpctl can't be
used to work with journald coredumps, as well as any other tools
that rely on journald to know about coredumps.
To solve the issue, let's have systemd-coredump try to write
systemd-journald coredump metadata to the journal. We have to be
careful though, since if journald coredumps, there's no active
reader on the receive end of the journal socket, so we have to make
sure we don't deadlock trying to write to the socket. To avoid the
deadlock, we put the socket in nonblocking mode before trying to
write to it.
|
| |
|
|
|
|
|
|
|
|
| |
When invoked as the coredump handler by the kernel, systemd-coredump's
stdout and stderr streams are closed. This is dangerous as this means
the fd's can get reallocated, leading to hard to debug errors such as
log messages ending up being appended to a compressed coredump file.
To avoid such issues in the future, let's bind stdout/stderr to
/dev/null so the file descriptors can't get used for anything else.
|
| |
|
|
| |
Fixes #23471
|
| |
|
|
| |
Let's make use of our new helper, and thus allow longer paths.
|
| |
|
|
|
|
|
|
|
|
| |
Suggested by Daniele Nicolodi:
https://github.com/systemd/systemd/pull/23160#discussion_r855853716
This is possible only if the macro is never used in #if, but only in C code.
This means that all places that use #if have to be refactored into C, but we
reduce the duplication a bit, and C is nicer to read than preprocessor
conditionals.
|
| | |
|
| |
|
|
| |
This also avoids multiple evaluations in STRV_FOREACH_BACKWARDS()
|
| |
|
|
|
|
|
|
|
|
|
| |
The approach to use '''…'''.split() instead of a list of strings was initially
used when converting from automake because it allowed identical blocks of lines
to be used for both, making the conversion easier.
But over the years we have been using normal lists more and more, especially
when there were just a few filenames listed. This converts the rest.
No functional change.
|
| |
|
|
|
|
| |
When checking if we look at the root directory we actually need to
compare both st_dev *and* st_ino. The existing check only checked the
latter. Fix that.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to 1G on 32bit systems)
Apparently 2G is too low for various real-life systems. But raising it
universally above 2^32 sounds wrong to me, since that makes no sense on
32bit systems, that we still support.
Hence, let's raise the limit to 32G on 64bit systems, and *lower* it to
1G on 32bit systems.
32G is 4 orders of magnitude higher then the old settings. Let's hope
that's enough for now. Should this not be enough we can raise it
further.
Fixes: #22076
|
| |
|
|
|
|
| |
Not having to provide the full path in the source tree is much
nicer and the produced lists can also be used anywhere in the source
tree.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The COREDUMP_EXE attribute is "optional", i.e. we continue to process the
crash even if we didn't acquire it. The coredump generation code assumed
that it is always available:
#5 endswith at ../src/fundamental/string-util-fundamental.c:41
[ endswith() is called with NULL here, and an assertion fails. ]
#6 submit_coredump at ../src/coredump/coredump.c:823
#7 process_socket at ../src/coredump/coredump.c:1038
#8 run at ../src/coredump/coredump.c:1413
We use the exe path for loop detection, and also (ultimately) pass it to
dwfl_core_file_report(). The latter seems to be fine will NULL, so let's just
change our code to look at COMM, which should be more reliable anyway.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2036517.
|
| | |
|
| |
|
|
| |
As in the previous commit, 'de' is used as the iterator variable name.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Allow later usage when we only want to fetch the JSON packaging metadata
|
| |
|
|
|
|
|
| |
Parsing objects is risky as data could be malformed or malicious,
so avoid doing that from the main systemd-coredump process and
instead fork another process, and set it to avoid generating
core files itself.
|
| |
|
|
|
| |
Note that c.f needs to be closed _before_ taking or freeing
the buf pointer, as it might be invalidated
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This was broken in a subtle way: we'd get an ELF ref, but not the right one,
so no metadata note would be found.
Change the parsing function to return 1 when it finds something, so that
we can return early only when that happens.
|
| |
|
|
| |
Make it compatible to the ulimit setting: unlimited
|
| |\
| |
| | |
various tweaks to mkdir code
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously the mkdir_label() family of calls was implemented in
src/shared/mkdir-label.c but its functions partly declared ins
src/shared/label.h and partly in src/basic/mkdir.h (!!). That's weird
(and wrong).
Let's clean this up, and add a proper mkdir-label.h matching the .c
file.
|
| |/ |
|
| |
|
|
|
|
|
|
| |
user-record.[ch] are about the UserRecord JSON stuff, and the UID
allocation range stuff (i.e. login.defs handling) is a very different
thing, and complex enough on its own, let's give it its own c/h files.
No code changes, just some splitting out of code.
|
