Previously we logged even info message from libselinux as USER_AVC's to
audit. For example, setting SELinux to permissive mode generated
following audit message,
time->Tue Feb 26 11:29:29 2019
type=USER_AVC msg=audit(1551198569.423:334): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: received setenforce notice (enforcing=0) exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
This is unnecessary and wrong at the same time. First, kernel already
records audit event that SELinux was switched to permissive mode, also
the type of the message really shouldn't be USER_AVC.
Let's ignore SELINUX_WARNING and SELINUX_INFO and forward to audit only
USER_AVC's and errors as these two libselinux message types have clear
mapping to audit message types.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11587.
We had a sample which was large enough that write(2) failed to push all the
data into the pipe, and an assert failed. The code could be changed to use
a loop, but then we'd need to interleave writes and sd_event_run (to process
the journal). I don't think the complexity is worth it — fuzzing works best
if the sample is not too huge anyway. So let's just reject samples above 64k,
and tell oss-fuzz about this limit.
When there are multiple ExecStop= statements, the next command would continue
to run even after TimeoutStopSec= is up and sends SIGTERM. This is because,
unless Type= is oneshot, the exit code/status would evaluate to SERVICE_SUCCESS
in service_sigchld_event()'s call to is_clean_exit(). This success indicates
following commands would continue running until the end of the list
is reached, or another timeout is hit and SIGKILL is sent.
Since long running processes should not be invoked in non-SERVICE_EXEC_START
commands, consider them for EXIT_CLEAN_COMMAND instead of EXIT_CLEAN_DAEMON.
Passing EXIT_CLEAN_COMMAND to is_clean_exit() evaluates the SIGTERM exit
code/status to failure and will stop execution after the first timeout is hit.
Fixes#11431
6f177c7dc0 caused key file errors to immediately fail, which would make it hard to correct an issue due to e.g. a crypttab typo or a damaged key file.
Closes#11723.
And before resolving NetDev names, check conditions in .network,
and if they do not match the system environment, drop the network
unit earlier.
Fixes#4211.
This isn't really necessary for the subsequent commit, but I expect that we'll
need to unpoison more often once we turn on msan in CI, so I think think this
change makes sense in the long run.
Clang includes -W#warning in -Werror, so the #warning used for msan would
be an error.
v2:
- use -Wno-error=... so that the warning is still emitted, but not as an error.