[Lxc-users] Kernel 2.6.33-rc6, 3 bugs container specific.
Serge E. Hallyn
serue at us.ibm.com
Wed Feb 3 16:21:48 UTC 2010
Quoting Jean-Marc Pigeon (jmp at safe.ca):
> > >
> > > The prink keeps writing in the global ring buffer and the syslog(2)
> > > writes to the "namespaced" ring buffer.
> > >
> > > Does it makes sense ?
> > Yeah, it's a nice alternative. Though (1) there is something to be said for
> > forcing a new ring buffer upon clone(CLONE_NEWUSER), and (2) assuming the
> > new ring buffer is pointed to from nsproxy, it might be frowned upon to do
> > an unshare/clone action in yet another way.
> > I still think our first concern should be safety, and that we should consider
> > just adding 'struct syslog_struct' to nsproxy, and making that NULL on a
> > clone(CLONE_NEWUSER). any sys_syslog() or /proc/kmsg access returns -EINVAL
> > after that. Then we can discuss whether and how to target printks to
> > namespaces, and whether duplicates should be sent to parent namespaces.
> /proc/kmsg=-EINVAL will resolve the own HOST: ring buffer corruption
> not sure what sys_syslog()=-EINVAL mean???, rsyslog MUST be able to
> run within CONT: right?
> printk namespaces duplicate and sent to parent namespace
> is not a good idea (duplicating&forwarding is done by tools as rsyslogd).
Heh, agreed, I just disagree that we should trust CONT to fwd stuff to
HOST, rather we should have HOST fwd stuff to CONT.
It comes down to whether HOST might need the info to determine what CONT
or someone attacking CONT is up to. To the extend that HOST will never be
fully safe from CONT (and if you think it is, even using kvm/vmware, then
you you're deluding yourself) I think it's misguided to keep information
> > After we start getting flexible with syslog, the next request will be for
> > audit flexibility. I don't even know how our netlink support suffices for
> > that right now.
> > (So, this all does turn into a big deal...)
> > -serge
> A bientôt
> Jean-Marc Pigeon Internet: jmp at safe.ca
> 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">
More information about the lxc-users