On sob, sty 10, 2009 at 08:21:53 -0800, Paul Menage wrote: > But converting a socket definition into a packet header that would be > sent/received on that socket is a fairly mechanical operation, and > after that you have the entire flexibility of the iptables API > available. So the connect() operation would construct a fake packet > header and send it through the iptable associated with the current > cgroup; if the packet was accepted the operation was permitted, else > the operation was denied. So if I understand you right, your proposed solution would be something akin to ipt_cgroup (matching packets originating from a cgroup, like ipt_owner matches uid/gid) plus netfilter hooks for blocking/remapping addresses passed to connect() and/or bind()? Or maybe a dedicated netfilter table with per-cgroup chains? I'd rather not invent some new userspace tools (to use the iptables API without /sbin/iptables) to manage the cgroup networking so I guess extending iptables (or iproute) would be the way to go in that case. Using the iptables API with connect() sending a fake packet, how would you represent "allow this connection, but bind() to 10.0.0.1 first"? Rewrite the source address in an iptables target? Am I right or completely off the mark? Best regards, Grzegorz Nosek _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers