Hello,
Just got your Email... (Sic :-})
On Sat, 2010-02-13 at 11:13 -0800, Eric W. Biederman wrote:
> Jean-Marc Pigeon <[email protected]> writes:
>
> > Added syslog.c such container /proc/kmsg and host /proc/kmsg
> > do not leak in each other.
> > Running rsyslog daemon within a container won't destroy
> > host kernel messages.
>
> If the goal is to not destroy the host kernel messages the much
> simpler solution would be to simply disable /proc/kmsg in the container.
> I expect we can get that for free with a some bug fixes to the user
> namespace (aka if you are not in the global namespace you can't
> touch /proc/kmsg).
>
> Additionally except for the possible exception of logging firewall rules
> I can't think of a case where I would want kernel printk's in anything
> other than the global kernel ring buffer.
Beside not to have HOST: syslog corrupted, my very original main
concern was indeed to feed container with its own firewall
rules.
Thinking about all this, I believe we are not bold enough.
We should be reporting all kernel message about devices/units
own/defined within the container to the own container syslog.
Let me try explain better by an example. To make container
networking you can use veth pair.
One of the veth pair is given to container and related
to container own network definition (eth0).
this TACAMO order "ip link set 'from_cont_veth' netns..."
make now the container "Take ChArge and Move Out" and
all kernel trouble to have the interface fully working
within the container should be reported to container
syslog.
Keep in mind, CONT: sys-admin could be a different
person than HOST: sys-admin. As long veth pair
is set properly, CONT: sys-admin problem setting
with eth0 is not a HOST: sys-admin concern.
A fully working container syslog will address/resolve this
kind of situation.
--
A bientôt
==========================================================================
Jean-Marc Pigeon Internet: [email protected]
SAFE Inc. Phone: (514) 493-4280
Fax: (514) 493-1946
Clement, 'a kiss solution' to get rid of SPAM (at last)
Clement' Home base <"http://www.clement.safe.ca";>
==========================================================================
_______________________________________________
Containers mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/containers
_______________________________________________
Devel mailing list
[email protected]
https://openvz.org/mailman/listinfo/devel
