Skip to content

Fix test failures when running as root

Simon McVittie requested to merge smcv/dbus:pass-tests-if-root into master

Building complicated software packages as uid 0 is probably a terrible idea in general, but people sometimes do builds as uid 0 (or otherwise with privileges) when running in an expendable container or VM. In particular, Debian's new Gitlab-CI infrastructure does lots of builds, some of them as root inside a container.

This exposed a few bugs:

  • The messagebus user (or whatever this OS calls it, sometimes dbus or _dbus) isn't guaranteed to exist at build time, only on installed systems. We correctly check whether this user exists before we setresuid() to it, but we didn't check whether it exists before running a fake system dbus-daemon as root, which we expect will drop its privileges to messagebus. We can't expect that to work if there is no messagebus user yet.
  • If we are dropping privileges from root to some other uid, we can't guarantee that the other uid will have read access to the directory where we put the just-built dbus-daemon.
  • In the real dbus-daemon, we have a single BusContext. If we have CAP_AUDIT_WRITE and Linux audit support is enabled, we open the audit socket (which has to be a global variable due to how the SELinux code calls into the audit code) when we create the BusContext, and close it on process shutdown. However, in the build-time unit tests for the dbus-daemon (which I suspect nobody has run as root before), we create one BusContext per test-case. We need to close the audit socket after each test-case, otherwise the next test case will open a redundant audit socket, which shows up as a file descriptor leak.
Edited by Simon McVittie

Merge request reports