SELinux logs before we have a chance to apply it, move it up as it
breaks TEST-04-JOURNAL:
[ 408.578624] testsuite-04.sh[11463]: ++ journalctl -b -q -u silent-success.service
[ 408.578743] testsuite-04.sh[11098]: + [[ -z Dec 03 13:38:41 H systemd-executor[11459]: SELinux enabled state cached to: disabled ]]
Follow-up for: bb5232b6a3
The regexp only worked if the sections were small enough for the size to
start with "0". I have an initrd that is 0x1078ec7e bytes, so the tests
would spuriously fail.
Follow-up for 2331c02d06.
Note, currently, the function is always called with SCMP_ACT_ALLOW as
the default action, except for the test. So, this should not change
anything in the runtime code.
arg_description was either set to arg_unit (i.e. a const char*), or to
char *description, the result of allocation in run(). But description
was decorated with _cleanup_, so it would be freed when going out of the
function. Nothing bad would happen, because the program would exit after
exiting from run(), but this is just all too messy.
Also, strv_join(" ") + shell_escape() is not a good way to escape command
lines. In particular, one the join has happened, we cannot distinguish
empty arguments, or arguments with whitespace, etc. We have a helper
function to do the escaping properly, so let's use that.
Fixup for 2c29813da3.
glibc starting using fchmodat2 to implement fchmod with flags [1], but
current version of libseccomp does not support fchmodat2 [2]. This is
causing problems with programs sandboxed by systemd. libseccomp needs to know
a syscall to be able to set any kind of filter for it, so for syscalls unknown
by libseccomp we would always do the default action, i.e. either return the
errno set by SystemCallErrorNumber or send a fatal signal. For glibc to ignore
the unknown syscall and gracefully fall back to the older implementation,
we need to return ENOSYS. In particular, tar now fails with the default
SystemCallFilter="@system-service" sandbox [3].
This is of course a wider problem: any time the kernel gains new syscalls,
before libseccomp and systemd have caught up, we'd behave incorrectly. Let's
do the same as we already were doing in nspawn since
3573e032f2, and do the "default action" only
for syscalls which are known by us and libseccomp, and return ENOSYS for
anything else. This means that users can start using a sandbox with the new
syscalls only after libseccomp and systemd have been updated, but before that
happens they behaviour that is backwards-compatible.
[1] https://github.com/bminor/glibc/commit/65341f7bbea824d2ff9d37db15d8be162df42bd3
[2] https://github.com/seccomp/libseccomp/issues/406
[2] https://github.com/systemd/systemd/issues/30250
Fixes https://github.com/systemd/systemd/issues/30250.
In seccomp_restrict_sxid() there's a chunk conditionalized with
'#if defined(__SNR_fchmodat2)'. We need to kep that because seccomp_restrict_sxid()
seccomp_restrict_suid_sgid() uses SCMP_ACT_ALLOW as the default action.
Since we accept that setfont(8) can fail with EX_OSERR and we dont treat it as
an error, dont log this failure at LOG_ERR.
Before:
-------
/usr/bin/setfont failed with exit status 71. [LOG_ERR]
Setting fonts failed with a "system error", ignoring. [LOG_NOTICE]
After:
-----
/usr/bin/setfont failed with a "system error" (EX_OSERR), ignoring. [LOG_NOTICE]
Setting source virtual console failed, ignoring remaining ones [LOG_NOTICE]
Follow-up for 93c9a9d235
DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for
removal in a future version. Use timezone-aware objects to
represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
The difference between the two is that .now(datetime.UTC) returns an object with
a timezone attached, "the numbers" are the same.
>>> datetime.datetime.utcnow(), datetime.datetime.now(datetime.UTC)
(datetime.datetime(2023, 12, 1, 9, 37, 53, 891669),
datetime.datetime(2023, 12, 1, 9, 37, 53, 891688, tzinfo=datetime.timezone.utc))
This value is fed to cryptography's x509.CertificateBuilder object, so as long
as it can accept a datetime object with tzinfo, the result should be identical.
A commit 6a42bdb37e ("hwdb: ieee1394-unit-function: add Sony
DVMC-DA1") is based on kernel feature unreleased yet (furthermore, not
merged yet). The original intension of new entry is to configure permission
of special file for FireWire character device, so this commit changes the
entry so that it can covers the issued case in existent version of Linux
kernel as out best effort.
When the new version of Linux kernel is released with the new feature,
then following commits would fulfill the hwdb with vendor and model names.
Let's consider the following case:
- the direction is down,
- no cached entry,
- the array has 5 entry objects,
- the function test_object() reutns TEST_LEFT for the 1st object,
- the 2nd, 3rd, and 4th objects are broken, so generic_array_bisect_step()
returns TEST_RIGHT for the object.
Then, previously, generic_array_bisect_step() updated the values like the following:
0th: (m = 5, left = 0, right = 4, i = 4) -> (m = 4, left = 0, right = 3, RIGHT)
1st: (m = 4, left = 0, right = 3, i = 1) -> (m = 4, left = 2, right = 3, LEFT)
2nd: (m = 4, left = 2, right = 3, i = 2) -> (m = 2, left = 2, right = 1, RIGHT) <- ouch!!
So, assert(left < right) in generic_array_bisect() was triggered.
See issue #30210.
In such situation, there is no matching entry in the array. By returning
TEST_GOTO_PREVIOUS, generic_array_bisect() handles the result so.
Fixes a bug introduced by ab8f553d1e.
Fixes#30210.
Let's consider the case that the 1st entry in an array is broken, but
n-th entry is valid. Then, if generic_array_get() is called to read
n-th object, the offset of the broken entry is cached by the function.
If generic_array_bisect() is followed, even if the matching entry is
valid, it always fail with -EBADMSG or friends, as the function test the
cached entry at the beginnning. Let's ignore the failure in testing the
cached entry.
Before this commit, between fdopen() (in parse_argv()) and fdset_remove(),
the serialization fd is owned by both arg_serialization FILE stream and fdset.
Therefore, if something wrong happens between the two calls, or if --deserialize=
is specified more than once, we end up closing the serialization fd twice.
Normally this doesn't matter much, but I still think it's better to fix this.
Let's call fdset_new_fill() after parsing serialization fd hence.
We set the fd to CLOEXEC in parse_argv(), so it will be filtered
when the fdset is created.
While at it, also move fdset_new_fill() under the second log_open(), so
that we always log to the log target specified in arguments.
Frantisek Sumsal
Luca Boccassi
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Mike Yuan
Neil Wilson
Дамјан Георгиевски
dependabot[bot]
Franck Bui
Daan De Meyer
Takashi Sakamoto
Joerg Behrmann