Re: Kernel 2.6.33-rc6, 3 bugs container specific.

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

Quoting Jean-Marc Pigeon (jmp-4qkeo2rQ0gg@public.gmane.org):
> Hello,
> 
> [...]
> > > 
> > > 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
from HOST.

> > 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-4qkeo2rQ0gg@public.gmane.org
> 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">
> ==========================================================================

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com