First spotted via https://bugzilla.redhat.com/show_bug.cgi?id=1846020
Containers that are not privileged and that bind mount /run (nova_scheduler and swift_proxy) will trigger selinux denials like the following:
type=USER_AVC msg=audit(1592337899.069:74465): pid=1284 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.DBus member=Hello dest=org.freedesktop.DBus spid=417423 scontext=system_u:system_r:container_t:s0:c162,c886 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=dbus permissive=0 exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'UID="dbus" AUID="unset" SAUID="dbus"
The reason for those is that by bind-mounting /run from the host, the container has access to /run/dbus/system_bus_socket and any NSS lookup (getent passwd/group) will take 30seconds until the systemd module will timeout:
$ time podman -u root -it nova_scheduler sh -c 'getent passwd &> /dev/null'
real 0m30.378s
The timeout does not happen if the container bind-mounts /run and is privileged because selinux does not block those. The implications of this is that any command that runs sudo/su/etc inside those two containers will take at least 30 seconds. In the environment I was given this actually caused messaging timeouts while nova_api was waiting for nova_scheduler. Fixing this issue made the environment functional again.
I have an idea how to mitigate that