At first I thought when using --copy-from= that it was copying in my
whole disk into a partition instead of just a partition into a
partition.
Let's make the log message clearer and say that we copy starting from an
offset.
This combines exec_context_determine_tty_size() and
terminal_set_size_fd() since we always use one after the other.
Also make exec_context_determine_tty_size() return void, since it cannot
fail.
Previously, Link.dhcp6_configured flag was unconditionally used even if
the route is configured based on the DHCPv4 protocol.
Follow-up for a27588d4e7 and
e49bad0179.
Otherwise we might still use the more restrictive limit when we get to
STDOUT_STREAM_RUNNING, causing unexpected line breaks in the journal
messages.
Follow-up to: 80e9720616Resolves: #29916
This is pretty low-level functionality, hence placed in systemd-analyze.
This is useful for working with systemd-cryptenroll --tpm2-device-key=,
as it acquires the SRK without requiring the full tpm2-tss tool set.
We already save it in PEM format, also store it TPM2_PUBLIC format next
to it. This is useful for usage with systemd-cryptenroll's
--tpm2-device-key= switch.
The tpm2_tpm2b_public_from_pem() invocation only makes sense when we
succeed to load the file from disk, hence we might do this together and
safe a conditionalization.
No change in behaviour, let's just move this over so that we can reuse
this in repart later (and don't have to export the ugly `sym_` function
pointer for it)
Let's define the same switches and their backing variables in the same
order, and let's make sure the enums and switches are named the same.
No actual code changes.
Currently, we round minimum sizes up and maximum size down, whereas
it should be the opposite as the current approach means that if the
same size is used for min and max, the min size will end up bigger
than the max size after rounding.
In 0531bded79 ("core: include peak memory in unit_log_resources()") new log
messages where added, however the size of the according arrays to hold the
messages was not adjusted.
Fixes: 0531bded79 ("core: include peak memory in unit_log_resources()")
This is pretty much the same stuff as `resolvectl monitor` does, and
allows us to run `busctl monitor` in a Type=notify unit which ensures
that `busctl` is really listening for messages once the unit is marked
as started.
Currently test_setpriority_closest assumes that setting RLIMIT_NICE to 30 will
fail if the process is unprivileged. If it succeeds, it assumes that the
process is privileged and setresuid and setresgid will succeed.
However, if RLIMIT_NICE is already >= 30, then setrlimit will succeed even if
the process is unprivileged. Guard against that by checking for permission
errors in setresuid and setresgid and skipping the full test if so.
Fixes#22896.
Currently empty epochs are not sealed. This allows an attacker to truncate
a sealed log and continue it without any problems showing when verifying the
log.
This partially addresses CVE-2023-31438. One way to extend this change to
address CVE-2023-31438 completely, would be to verify that there is exactly
one seal per epoch (and not sealing when the epoch has not ended yet).
the change also adds a journal-file flag: HEADER_COMPATIBLE_SEALED_CONTINUOUS
this flag indicates that a journal file is sealed continuously and decides whether
any missing crypto epochs should trigger a warning or an error.
O_CREAT doesn't make sense for fd_reopen, since we're
working on an already opened fd. Also, in fd_reopen
we don't handle the mode parameter of open(2), which
means we may get runtime error like #29938.
AFAICT there's no reason to keep removed entries in the Hashmap
(although it doesn't break anything either). The only use of this
hashmap is in udev_rule_apply_token_to_event(), which just retrieves the
value using hashmap_get(), hence there's no difference there between an
existing entry with a NULL value and a missing entry.
Then, this fixes the following issues:
- if dns_packet_append_zone() for other transaction is failed with
EMSGSIZE, the previously added key was not removed,
- if dns_transaction_prepare() for other transaction returns 0, then
we restated the loop without dropping previously appended keys, which
might not be necessary any more.
The order of search domains is important information. We shouldn't
obscure it by sorting the search domains when printing.
Fixes: af781878d5 ("resolvectl: sort domain/nta output")