On pią, sty 09, 2009 at 01:58:42 -0800, Paul Menage wrote:> While something to allow restricting network access from tasks in a> cgroup is useful, the basic problem with the patches that have been> proposed is the userspace API.> > Once an API makes it into the kernel, we have to support it more or> less indefinitely. So that means we want to come up with something> that will satisfy say 95% of users *before* it gets anywhere near> mainline. Certainly. The patch is RFC, not mainline-me-now. While it scratches mycurrent itch, I'd definitely want it to be more useful. I just wanted toreceive some comments on the overall idea before I invest way too muchtime in it. > So for example, some people might want multiple IP addresses; others> might want to specify a subnet, but exclude certain addresses;> controlling which ports or port-ranges can be bound to is also useful> (and in fact is what I'd be most interested in). ...and some people mignt not want the loopback special case. So we'dneed a black- and whitelist of: IP address [/netmask] [port [- port]] right? Would that cover a reasonable set of use cases? If there aregoing to be multiple addresses, we'd probably want some mechanism todetermine which one should be used for remapping INADDR_ANY. BTW, do youwant to restrict connect() source ports too? > Ideally we'd avoid making up a brand new userspace API for this. It> would be great if we could somehow make use of the iptables API, which> already has support for specifying these kinds of conditions. The iptables interface is nice but only works with network packets andnot sockets and I'd find bind() remapping via iptables rather strange.I'm currently using iptables to SNAT outgoing connections per uid butI find the cgroup idea rather appealing (as many resources as possiblemanaged from a single virtual directory with simple shell tools). So, are you opposed to the current implementation (single IP address) orto the interface (a file in cgroupfs)? > I did once hack together a proof-of-concept that let you use iptables> for controlling connect/accept/bind operations, but it was a complete> mess and wouldn't survive code review :-) <shudder> :) Best regards, Grzegorz Nosek_______________________________________________Containers mailing listContainers@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.linux-foundation.org/mailman/listinfo/containers
