projectatomic
(SPC) communication with host system bus
Currently we do -v /run:/run for --spc. This has a lot of effects, but the main one here is that tools in the container can see the host system bus.
Which means when I try to do:
useradd walters
su - walters
I get a long delay, which appears to be pam_systemd in the PAM stack trying to talk to logind but being denied by policy:
[ 6527.306817] type=1107 audit(1467944702.901:5): pid=972 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=error error_name=org.freedesktop.DBus.Error.InvalidArgs dest=:1.34 spid=987 tpid=16805 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:system_r:spc_t:s0 tclass=dbus
My intuition here is that we should just turn off the PAM stack entirely inside Docker containers in general. Removing pam_systemd.so in the base image would likely make sense...but I'm opening this issue here since it's a general case of "we need to think about the effects of the /run bind mount".
Well I want to allow all system and session bus clients to dbus chat with spc_t, since I could set one up as a dbus service. We currently allow all domains to connecto spc_t over unit domain sockets.
I have modified the spc_t policy to allow these access above. But there are potentially other issues with /run being mounted into a container.
Who do I contact about fixing the centos/tools containers run label?
But that said though, I don't think I want my users created inside a container registered with the host logind, and I think the fix is likely to neuter the PAM stack. The mechanical question is how to do it...create a pam-stub package or something? Or we could resort to editing the files in %post.
spc_t is an unconfined domain, these AVC's are about confined domains communicating with spc_t.
I agree for this issue we should fix the pam stack.
Cleaning up atomic issues.
@cgwalters What do you want to do with this one?