Message-ID: <20121127135838.GB4127@sergelap>
Date:	Tue, 27 Nov 2012 07:58:38 -0600
From:	Serge Hallyn <serge.hallyn@...onical.com>
To:	Libo Chen <chenlibo.3@...il.com>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>, netdev@...r.kernel.org,
	containers@...ts.linux-foundation.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH RFC 3/5] printk: modify printk interface for
 syslog_namespace

Quoting Libo Chen (chenlibo.3@...il.com):
> From: Libo Chen <clbchenlibo.chen@...wei.com>
> 
> On 2012-11-25 12:28, Serge E. Hallyn wrote:
> > Quoting Libo Chen (chenlibo.3@...il.com):
> >> On 2012/11/22 1:49, Serge E. Hallyn wrote:
> >>
> >>> I notice that you haven't made any changes to the struct cont.  I
> >>> suspect this means that to-be-continued msgs from one ns can be
> >>> erroneously mixed with another ns.
> >>>
> >> Yes, I confirmed this problem. There will be erroneously mixed with another ns.
> >> Thank you very much.
> >>
> >>> You said you don't mind putting the syslogns into the userns.  If
> >>> there's no reason not to do that, then we should do so as it will
> >>> remove a bunch of code (plus the use of a new CLONE flag) from your
> >>> patch, and the new syslog(NEW_NS) command from mine.
> >>>
> >> I agree with you, both are removable.
> >>
> >>> Now IMO the ideal place for syslog_ns would be in the devices ns,
> >>> but that does not yet exist, and may never.  The bonus to that would
> >>> be that the consoles sort of belong there.  I avoid this by not
> >>> having consoles in child syslog namespaces.  You put the console in
> >>> the ns.  I haven't looked closely enough to see if what you do is
> >>> ok (will do so soon).
> >>>
> >>> WOuld you mind looking through my patch to see if it suffices for
> >>> your needs?  Where it does not, patches would be greatly appreciated
> >>> if simple enough.
> >>
> >> follow your patch, I can see inject message by "dmesg call" in container, is right?
> > 
> > If I understand you right, yes.
> > 
> >> I am worry that I debug  or see messages from serial ports console in some embedded system,
> >> since console belongs to init_syslog,  so the message in container can`t be printed. 
> > 
> > Sorry, I don't understand which way you're going with that.  Could you
> > rephrase?  You want to prevent console messages from going to a
> > container?  (That should definately not happen)  Or something else?
> > 
> 
> I reviewed your patch, and found that console could only print messages
> belonging to init_syslog.
> 
> So the message belongs to container syslog can not be printed from console,
> but only "dmesg call" in user space.  Is that right?
> 
> For example, the messages can not be outputed automatically from serial port
> as a kind of consoles on some embedded system.

Oh, I see.  I basically thought this was a feature, not a problem :)  But
that wasn't meant to be a core part of my patchset, rather I wasn't quite
sure how best to handle it, so I put it off for later.  My main concern is
that if consoles in containers are supported, this must NOT lead to
kernel module loading from the container.

> And I am not sure if there are no other problems.

Ok, I will write a new patch which would (a) try to address the consoles,
(b) move the syslogns into the user_ns (making it no longer a syslog_ns),
and (c) adding some users of ns_printk (borrowing the ones from your
set for starters).

thanks,
-serge
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists