Richard Guy Briggs <r...@redhat.com> writes: > On 14/02/28, Eric W. Biederman wrote: >> While reading through 3.14-rc1 I found a pretty siginficant mishandling >> of network namespaces in the recent audit changes. >> >> In struct audit_netlink_list and audit_reply add a reference to the >> network namespace of the caller and remove the userspace pid of the >> caller. This cleanly remembers the callers network namespace, and >> removes a huge class of races and nasty failure modes that can occur >> when attempting to relook up the callers network namespace from a pid_t >> (including the caller's network namespace changing, pid wraparound, and >> the pid simply not being present). > > Ok, so I see that avoiding pid_t in struct audit_reply and struct > audit_netlink_list is necessary. Why not switch to struct pid? > > How does this patch solve a caller's network namespace changing?
This solves the callers network namespace changing or the caller going away entirely (a much more serious concern) because we capture the network namespace at the time of the request when the caller is in the kernel. I would have simply captured the socket we want to reply on but there did not appear to be a good way to do that. Reading through it again capturing current->nsproxy->net_ns is striclty wrong. We should be capturing sock_net(NETLINK_CB(skb).sk). The network namespace of the requesting socket. That handles even weird cases of passing file descriptors between processes in different network namespaces. (An incremental patch to change to code to selct the network namespace of the requesting socket to follow in a moment). Still what my patch implements today at least means we won't oops the kernel if the audit process exits early, and causes get_net_ns_by_pid to return NULL. This whole code path is so crazy because what we really should be doing is sending the packets in nonblocking mode and just dropping packets if the receiving socket does not have enough socket buvffers. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
