Re: containerized syslog

Re: containerized syslog

[Serge E. Hallyn]

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.

-serge

Re: containerized syslog

[Matt Helsley]

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).

Cheers,
	-Matt Helsley

Re: containerized syslog

[Matt Helsley]

On Sat, Feb 13, 2010 at 07:58:13AM -0800, Matt Helsley wrote:

<snip>

> 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

Sorry, I don't think I worded this clearly. "some other form" means a
non-syslog_ns which is "relevant" to the printk e.g. a netns for
iptables code.

Cheers,
	-Matt Helsley

Re: containerized syslog

[Serge E. Hallyn]

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

Containerized syslog

[Jean-Philippe Menil]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

Hi,

I'm playing with containers under debian (squeeze, 2.6.33.3) with the 
lxc tools.
I'm really happy about all the features (attach veth on bridge, filter 
with iptables inside the containers, etc ...), and i was thinking to 
replace some of our vservers (and maybe some of our kvm) with this solution.

But actually, i experiment a problem with the iptables logs:
i've iptables on the host to filter some container, basically a squid 
proxy. I've another container who act as router, and he has his own 
iptables inside.
All the log are deported to a dedicated syslog server.
It appear that, the iptables log of the host are also deported by the 
syslog container (proxy).

Some of our guest (container, vserver, etc ) are administer by other 
sys-admin, that should not have access to theses informations.

This point is blocking me today, before going into production with 
containers.

I've seen some patch made by Jean-Marc Pigeon about this problem,
but they have not been commited.

Is there any reason for that?
Can someone advice me to circumvent this problem?

Thanks a lot.

Regards.

[-- Attachment #2: jean-philippe_menil.vcf --]
[-- Type: text/x-vcard, Size: 458 bytes --]

begin:vcard
fn:Jean-Philippe Menil
n:Menil;Jean-Philippe
org;quoted-printable:Universit=C3=A9 de Nantes;IRTS - DSI
adr;quoted-printable:;;2, rue de la Houssini=C3=A8re;Nantes;Loire-Atlantique;44332;France
email;internet:jean-philippe.menil-zanJymNeSEOeCSforKHNpg@public.gmane.org
title;quoted-printable:Administrateur R=C3=A9seau
tel;work:02.51.12.53.92
tel;fax:02.51.12.58.60
x-mozilla-html:FALSE
url:http://www.criun.univ-nantes.fr/
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 206 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers