Quoting Matt Helsley (matthltc@xxxxxxxxxx): > On Wed, May 12, 2010 at 11:15:05PM +0200, Daniel Lezcano wrote: > > Jean-Philippe Menil wrote: > > > Hi, > > > > > > I'm playing with containers under debian (squeeze, 2.6.33.3) with the > > > lxc tools. > > > I'm really happy about all the features (attach veth on bridge, filter > > > with iptables inside the containers, etc ...), and i was thinking to > > > replace some of our vservers (and maybe some of our kvm) with this > > > solution. > > > > > > But actually, i experiment a problem with the iptables logs: > > > i've iptables on the host to filter some container, basically a squid > > > proxy. I've another container who act as router, and he has his own > > > iptables inside. > > > All the log are deported to a dedicated syslog server. > > > It appear that, the iptables log of the host are also deported by the > > > syslog container (proxy). > > > > > > Some of our guest (container, vserver, etc ) are administer by other > > > sys-admin, that should not have access to theses informations. > > > > > > This point is blocking me today, before going into production with > > > containers. > > > > > > I've seen some patch made by Jean-Marc Pigeon about this problem, > > > but they have not been commited. > > > > I thing a consensus was not reach. The big deal with syslog is netfilter > > logs in an interrupt context where it is difficult to find the right log > > buffer ring as we are not in the process context making possible to > > identify the namespace. > > > > IMHO, there are two parts to implement, (1) multiple instances of > > /dev/log with a new ring buffer each time attached to the file and > > Just for reference, here are some archived mailing list threads on the > subject of containerized syslog: > > http://www.mail-archive.com/devel@xxxxxxxxxx/msg20104.html > http://thread.gmane.org/gmane.linux.kernel.containers/16526 > > > (2) > > add an iptables rules to specify the file to log. This approach allows > > to get rid of namespace (in all the cases the clone flags are exhausted > > now), and provides a generic mechanism for other use cases (eg. separate > > logs for iptables) different from a container specific problem. > > (3) Security implications. > > Depending on how the syslog is split off, whether the host > expects to be "Cc'd", etc. there could be some security > implications. More importantly, the syslog control syscalls need > to be modified to at least prevent containers from changing syslog > policy of the host. Serge could probably explain this much better > than I can (cc'd). Here's a thread on the subject: > > http://lwn.net/Articles/378472/ Yes, i think that's the first step. Then, as Oren and Matt were discussing on irc, we can talk about a userspace daemon on the host forwarding either syslog or audit msgs to containers as appropriate. This leaves that policy chunk in userspace, but we'd still have to decide on a way to mark messages (which is why audit would be easier). First question then is how do we identify a container? With pidns we can point to a definitive global pid for the container init task. For netns, no such thing. -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
