shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-12-21 13:34:21 +03:00
Code

test-audit-util: do not assert on unknown container managers

Browse Source 
The test can be ran on systems that are not booted on systemd, and/or
in a strange and unknown container manager stub pid1 that does not
behave as we expect, so making assertions based on the precise state
of an unknown, foreign pid1 is not guaranteed to yield the expected
results and may fail at any given time.

More specifically, this happens when building systemd on the buildd
network, which is used to build packages in Debian/Ubuntu:

 Assertion 'audit_session_from_pid(&pid1, &sessionid) == -ENODATA' failed at src/test/test-audit-util.c:27, function test_audit_loginuid_from_pid(). Aborting.

https://buildd.debian.org/status/fetch.php?pkg=systemd&arch=amd64&ver=257%7Erc2-1&stamp=1731712935&raw=0

Add a failsafe and print a loud complaint in the unit test, asking to
fix the container manager, if this situation is detected.
This commit is contained in:
Luca Boccassi 2024-11-22 12:50:04 +00:00
parent 9bf6ffe166
commit 6e06b80854
1 changed files with 26 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
src/test/test-audit-util.c
View File

@ -2,6 +2,7 @@
#include "audit-util.h"
#include "tests.h"
#include "virt.h"
TEST(audit_loginuid_from_pid) {
_cleanup_(pidref_done) PidRef self = PIDREF_NULL, pid1 = PIDREF_NULL;
@ -17,7 +18,22 @@ TEST(audit_loginuid_from_pid) {
if (r >= 0)
log_info("self audit login uid: " UID_FMT, uid);
ASSERT_ERROR(audit_loginuid_from_pid(&pid1, &uid), ENODATA);
/* pid1 at build time does not necessarily have to be systemd, it could be anything and be in any
* state outside of our control, as any custom-built, unknown and weird container manager stub pid1
* might be in use. The audit helper should catch this on container-other and return -ENODATA
* already, but we cannot have any coverage of this case, so a risk of regression is always present.
* To be on the safe side, assert only on known container solutions (or VMs/bare-metal), and print a
* loud warning and complain, asking to fix the audit setup of the container manager, if it is an
* unknown one. As a specific example, on the Debian buildd network the stub pid1 is not systemd,
* and has a sessionid. */
r = audit_loginuid_from_pid(&pid1, &uid);
if (detect_container() != VIRTUALIZATION_CONTAINER_OTHER)
ASSERT_ERROR(r, ENODATA);
else if (r != -ENODATA)
log_error("audit_loginuid_from_pid on pid1 unexpectedly returned %d instead of -ENODATA. "
"This likely suggests that the container manager under which this test is run "
"has incorrectly set up the audit subsystem, as the stub pid1 is not supposed to "
"have an audit login id, and it should be fixed.", r);
uint32_t sessionid;
r = audit_session_from_pid(&self, &sessionid);
@ -26,7 +42,15 @@ TEST(audit_loginuid_from_pid) {
if (r >= 0)
log_info("self audit session id: %" PRIu32, sessionid);
ASSERT_ERROR(audit_session_from_pid(&pid1, &sessionid), ENODATA);
/* As above. */
r = audit_session_from_pid(&pid1, &sessionid);
if (detect_container() != VIRTUALIZATION_CONTAINER_OTHER)
ASSERT_ERROR(r, ENODATA);
else if (r != -ENODATA)
log_error("audit_session_from_pid on pid1 unexpectedly returned %d instead of -ENODATA. "
"This likely suggests that the container manager under which this test is run "
"has incorrectly set up the audit subsystem, as the stub pid1 is not supposed to "
"have an audit session id, and it should be fixed.", r);
}
static int intro(void) {