Ensure all realtime timestamps in a journal file are strictly
ordered on write as a defense-in-depth measure. All known callers of
journal_file_append_entry and journal_file_copy_entry, which call this
function, should be able to handle the error by rotating the journal.
This is especially helpful for systems with RTC local time enabled,
where all log entries from initramfs might be recorded as several hours
later than it actually is, which won't get caught by journald during log
flushing. In those cases, the resulting inconsistency can cause libsystemd
to loop infinitely through journal files as observed in
`abrt-dump-journal-oops`.
CURLOPT_PROTOCOLS [0] was deprecated in libcurl 7.85.0 with
CURLOPT_PROTOCOLS_STR [1] as a replacement, causing build warnings/errors:
../build/src/import/curl-util.c: In function ‘curl_glue_make’:
../build/src/import/curl-util.c:255:9: error: ‘CURLOPT_PROTOCOLS’ is deprecated: since 7.85.0. Use CURLOPT_PROTOCOLS_STR [-Werror=deprecated-declarations]
255 | if (curl_easy_setopt(c, CURLOPT_PROTOCOLS, CURLPROTO_HTTP|CURLPROTO_HTTPS|CURLPROTO_FILE) != CURLE_OK)
| ^~
In file included from ../build/src/import/curl-util.h:4,
from ../build/src/import/curl-util.c:6:
/usr/include/curl/curl.h:1749:3: note: declared here
1749 | CURLOPTDEPRECATED(CURLOPT_PROTOCOLS, CURLOPTTYPE_LONG, 181,
| ^~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Since there's no grace period between the two symbols, let's resort
to a light if-def-ery to resolve this.
[0] https://curl.se/libcurl/c/CURLOPT_PROTOCOLS.html
[1] https://curl.se/libcurl/c/CURLOPT_PROTOCOLS_STR.html
CURLINFO_PROTOCOL has been deprecated in curl 7.85.0 causing compilation
warnings/errors:
../build/src/import/pull-job.c: In function ‘pull_job_curl_on_finished’:
../build/src/import/pull-job.c:142:9: error: ‘CURLINFO_PROTOCOL’ is deprecated: since 7.85.0. Use CURLINFO_SCHEME [-Werror=deprecated-declarations]
142 | code = curl_easy_getinfo(curl, CURLINFO_PROTOCOL, &protocol);
| ^~~~
In file included from ../build/src/import/curl-util.h:4,
from ../build/src/import/pull-job.h:6,
from ../build/src/import/pull-common.h:7,
from ../build/src/import/pull-job.c:16:
/usr/include/curl/curl.h:2896:3: note: declared here
2896 | CURLINFO_PROTOCOL CURL_DEPRECATED(7.85.0, "Use CURLINFO_SCHEME")
| ^~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Since both CURLINFO_SCHEME and CURLINFO_PROTOCOL were introduced in
the same curl version (7.52.0 [0][1]) we don't have to worry about
backwards compatibility.
[0] https://curl.se/libcurl/c/CURLINFO_SCHEME.html
[1] https://curl.se/libcurl/c/CURLINFO_PROTOCOL.html
Otherwise, when a new syspath is assigned to the sd-device object,
sd_device_get_sysname() or _sysnum() will provide an outdated device
name or number.
This commit adds support for attaching extra metadata to log
messages written to the journal via log.h. We keep track of a
thread local log context in log.c onto which we can push extra
metadata fields that should be logged. Once a field is no longer
relevant, it can be popped again from the log context.
On top of this, we then add macros to allow pushing extra fields
onto the log context.
LOG_CONTEXT_PUSH() will push the provided field onto the log context
and pop the last field from the log context when the current block
ends. LOG_CONTEXT_PUSH_STRV() will do the same but for all fields in
the given strv.
Using the macros is as simple as putting them anywhere inside a block
to add a field to all following log messages logged from inside that
block.
void myfunction(...) {
...
LOG_CONTEXT_PUSH("MYMETADATA=abc");
// Every journal message logged will now have the MYMETADATA=abc
// field included.
}
For convenience, there's also LOG_CONTEXT_PUSHF() to allow constructing
the field to be logged using printf() syntax.
log_context_new()/log_context_free() can be used to attach a log context
to an async operation by storing it in the associated userdata struct.
This allows passing pre-allocated buffers via compound initializers
to snprint_ok(). If snprintf_ok() is a macro, the compound initializer
block will be scoped to the macro block, if snprint_ok() is a function,
the compound initializer block will be scoped to the block from which
snprintf_ok() is called.
Since the files with generated directives are now automatically
generated during build, they're now under the respective build directory
which the current oss-fuzz CI script didn't account for.
Follow-up to: #24958Resolves: #25859
In 'data' we get the location passed in we write stuff, and that's not
the Manager object.
And we neither get the Manager passed in via 'userdata', because at the
time we parse the emergency action for the manager the Manager is not
actually allocated yet.
hence, let's fix this differently, and pass in the user/system mode
descriptor via the 'ltype' argument.
Fixes: #25933
When built with ACL support, we might be processing a tmpfiles
entry where there's no cause for us to call parse_acls_from_arg,
then we get to the end of parse_line without having ever populated
i.{acl_access, acl_default}.
Then we pass a null pointer into acl_free().
From UBSAN w/ GCC 13.0.0_pre20230101:
```
$ systemd-tmpfiles --clean
/var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44:14: runtime error: applying non-zero offset 18446744073709551608 to null pointer
#0 0x7f65d868b482 in acl_free /var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44
#1 0x55fe7e592249 in item_free_contents ../systemd-9999/src/tmpfiles/tmpfiles.c:2855
#2 0x55fe7e5a347a in parse_line ../systemd-9999/src/tmpfiles/tmpfiles.c:3158
#3 0x55fe7e5a347a in read_config_file ../systemd-9999/src/tmpfiles/tmpfiles.c:3897
#4 0x55fe7e590c61 in read_config_files ../systemd-9999/src/tmpfiles/tmpfiles.c:3985
#5 0x55fe7e590c61 in run ../systemd-9999/src/tmpfiles/tmpfiles.c:4157
#6 0x55fe7e590c61 in main ../systemd-9999/src/tmpfiles/tmpfiles.c:4218
#7 0x7f65d7ebe289 (/usr/lib64/libc.so.6+0x23289)
#8 0x7f65d7ebe344 in __libc_start_main (/usr/lib64/libc.so.6+0x23344)
#9 0x55fe7e591900 in _start (/usr/bin/systemd-tmpfiles+0x11900)
```
Let's pass USEC_INFINITY from sd_event_source_set_time_relative() to
sd_event_source_set_time() instead of raising EOVERFLOW.
We should raise EOVERFLOW only if your addition fails, but not if the
input already is USEC_INFINITY, since it's an entirely valid operation
to have an infinite time-out, and we should support that.
msizanoen1
Frantisek Sumsal
Lennart Poettering
Yu Watanabe
Jan Janssen
Mike Yuan
Daan De Meyer
Siddhesh Poyarekar
Luca Boccassi
dependabot[bot]
Quentin Deslandes
Sam James