Re: container sharing /proc/kmsg???

["Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

Quoting Jean-Marc Pigeon (jmp-4qkeo2rQ0gg@public.gmane.org):
> Hello,
> 
> Hello,
> 
> > > 	Namely, I have in iptables, reject packet logging
> > > 	on the HOST, as soon rsyslog is started on one
> > > 	container, I can't see my reject packet log anymore. 
> > > 
> [...]
> 
> > > 	If I am right, should ALL /proc/kmsg be isolated from
> > > 	each other???
> > > 	
> > > 	How could it be done??
> > 
> > Well, the results of do_syslog() should be containerized.  Kernel
> > messages (oopses for instance) should always go to the initial
> > container.  Shouldn't be hard to do, but the question is what do
> > we tie it to?  User namespace?  Network namespace?  Eric, is this
> > something you've thought about at all?
> > 
> > I'm tempted to say userns makes the most sense - if you start a new
> > userns you likely always want private syslog, whereas with netns and
> > pidns you may not.
> 
> 	I am not a kernel expert, but my guess/answer is
> 	"user namespace".
> 	I mean container /proc return only process number/info
> 	pertaining to container.
> 	Likewise /proc/kmsg should be container own, after all
> 	if iptables rules can be specific to container AND
> 	iptables can log via kmsg, then message must be reported
> 	to container (and duplicated to kmsg host?) and do not
> 	make trouble to host.

/proc/kmsg is just hooked int do_syslog(), the same helper used
by sys_sylog(), so we should be able to address this purely in
kernel/printk.c.

If I get some time tonight I may whip up a proof of concept, though
if anyone else wants to have at, please do.

-serge