[PATCH 1/1] Syslog are now containerized

[Matt Helsley]

On Sat, Feb 13, 2010 at 04:56:16PM -0500, Jean-Marc Pigeon wrote:
> Hello,
> 
> [...]
> > Tracking all of these accesses down and ensuring they are only done
> > from "its container context" is difficult or impossible. It's not as
> > easy as you seem to think. In some cases the same resource could be
> > shared between containers. Which should we access it from then?
> 
> 	How come?! ressources (a device, Iptable rules,...)

Because it's kernel code. Kernel code implements interrupt handlers,
schedules processes, and even does work inside kernel threads. We
can't guarantee that some of the work initiated by a process is
always done with current == <the process>. Hence ensuring that
these accesses are only done from "its container context" is not
reasonable. The best we can do is ensure that accesses from the
processes in the container are contained.

> 	containerized within one container could be shared by 
> 	another unrelated container?.

Yes. namespace boundaries only coincide if userspace chooses to
make them coincide. For example, the tasks in a network namespace
do not necessarily all share the same mount namespace.

> 	Does this means (simple example) someone change
> 	iptable rules for one container that could change 
> 	another unrelated container behavior ?!...no way...

Two "unrelated containers" would share the same iptables rules
so long as they share a network namespace.

<snip>

> > > 	My proposal is a clear cut, if a ressource is containerized 
> > > 	report to CONT: (containerized) syslog... no question ask.
> > 
> > That part of the proposal is simple and makes alot of sense. The
> > ramifcations of it on kernel code are not simple and often there's
> > no clean way to do it.
> 	Well, this trouble me somewhat....
> 	2.6.18-128.2.1.el5.028stab064.7 (just an example, I am using
> 	day to day), is containerising iptables an other syslogs 
> 	nice way....,

Er.. you have a 2.6.18 kernel "containerising iptables an other syslogs"?
I didn't think iptables supported network namespaces until somewhat
recently. Is this an openvz-patched kernel you're talking about?

> 	We are now 2.6.33 you are telling me what was experimented,
> 	learned, monthssss ago can't still be implemented 
> 	in current kernel main stream?.... 

Careful. "no clean way to do it" does not mean "can't be done".

Cheers,
	-Matt Helsley