Re: containerized syslog

["Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>]

Quoting Matt Helsley (matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org):
> On Thu, Feb 11, 2010 at 01:29:52PM -0600, Serge E. Hallyn wrote:
> > Quoting Jean-Marc Pigeon (jmp-4qkeo2rQ0gg@public.gmane.org):
> > > Hello,
> > > 
> > > 
> > > > 
> > > > Thanks Jean-Marc.  But this really isn't doing most of what I'd
> > > > recommended in my last emails (both public and private.  In
> > > > particular:
> > > [....]	
> > > > 
> > > > syslog_ns should be moved into nsproxy and unshared with a
> > > > separate clone(CLONE_SYSLOG);
> > > 	This this not a problem.
> > > 	My understanding a new clone flag was not an option
> > > 	as we are short in CLONE flag.
> > > 	No design nor arch problem if we set  CLONE_SYSLOG
> > > 	to be 0x100000000  ?????
> > > 
> > > 	If moved in nsproxy what is the hook to
> > > 	get the "current context". (used current_user_ns()
> > > 	as it was in user_namespace).
> > > 
> > > 
> > > [...]	
> > > 
> > > > That was why I suggested:
> > > [...]
> > > > >! 4. take a printk call like the iptables ones you want and turn
> > > > >! int into nsprintk syscall.
> > > > >! 
> > > 
> > > 	If my understanding is right you propose to use a
> > > 	special nsprintk to be used by iptable such
> > > 	we can send "packet log" in "container context"
> > > 	Right?
> > > 
> > > 	Logic is weak.
> > 
> > No logic is irrefutable :)  Because:
> > 
> > > 	1)
> > > 	The way I changed printk, so far, make of it a "de facto"
> > > 	nsprintk. So when called from netfilter, nsprintk
> > > 	is still stay in HOST: context. My understanding,
> > 
> > No, it could be called from the context of a task in any
> > random container.
> 
> Your comments seem good. However, I do have an issue with the
> idea of finding a single syslog corresponding to the netns for
> a hypothetical printk in iptables.
> 
> What happens with:
> 
> /* in init_syslog_ns */
> clone(CLONE_SYSLOG) /* syslog_ns 1 */
> clone(CLONE_SYSLOG) /* syslog_ns 2 */
> <do something with iptables in the netns which triggers a printk>
> 
> Even though that same printk is relevant to three "syslogs", it'll
> only go to one, correct? If so, my feeling is that nsprintk
> shouldn't take a syslog_ns directly. It should take some other
> form of namespace and then write to the syslog of all the
> nsproxies which share that namespace (a netns in this case).

Could do that - but I think it'd be fair to just keep track of
a single netns->syslog_ns, namely the one which corresponded
to the netns when netns was created.

Don't allow unshare of syslog_ns, only clone.  That ensures that
the init task in a container will always be tied to the same
net, pid, and syslog namespaces, giving us a point of sanity.

-serge