Serge Hallyn <serge.hallyn@xxxxxxxxxx> writes: > Quoting Eric Paris (eparis@xxxxxxxxxx): >> So the kernel socket(s) would be per network namespace, but we divide >> messages per user namespace? Which socket do I send them on, >> considering the possible crazy many<->many mappings between user and >> network namespaces. It all makes me cry a little. > > not many-many - each netns is owned by exactly one userns. The userns > from which the netns was created. Doh. I missed this question and I think I misunderstood when Eric Paris was talking about multicasting audit messages. If what we are really talking about is sending some audit messages to an auditd in a container what appears obvious to me is that we define a per user namespace capability something like CAP_AUDIT_CONTROL. That does most or all of what CAP_AUDIT_CONTROL does in the init user namespace. Especially capturing audit_pid and audit_nlk_portid to decide who to send the message to. Something like: struct audit_control { int initialized; pid_t pid; u32 nlk_portid; }; struct user_namespace { ... struct audit_contol audit; }; Then the transmission would be something like: struct user_namespace *user_ns = ...; for (;;) { if (ns->audit_pid) { err = netlink_unicast(ns->audit.sock, skb, ns->audit.nlk_portid, 0); } if (!ns->parent) break; ns = ns->parent; } If someone finds auditd interesting enough to do that work. In general I think it only makes sense if we can reuse the existing userspace auditd. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers