|| ||Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA-AT-public.gmane.org> |
|| ||Daniel Lezcano <daniel.lezcano-GANU6spQydw-AT-public.gmane.org> |
|| ||Re: [lxc-devel] Containerized syslog |
|| ||Thu, 13 May 2010 14:21:39 -0700|
Serge Hallyn <serue-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8-AT-public.gmane.org>,
|| ||Article, Thread
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, 188.8.131.52) 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:
> 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:
to post comments)