Hello,
On Sat, 2010-02-13 at 10:11 -0800, Matt Helsley wrote:
> On Thu, Feb 11, 2010 at 11:48:43AM -0600, Serge E. Hallyn wrote:
> > Quoting Jean-Marc Pigeon ([email protected]):
> > > Added syslog.c such container /proc/kmsg and host /proc/kmsg
> > > do not leak in each other.
> > > Running rsyslog daemon within a container won't destroy
> > > host kernel messages.
> >
> > 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:
> >
> > > index cc4f453..3d0c73e 100644
> > > --- a/include/linux/user_namespace.h
> > > +++ b/include/linux/user_namespace.h
> > > @@ -14,6 +14,7 @@ struct user_namespace {
> > > struct hlist_head uidhash_table[UIDHASH_SZ];
> > > struct user_struct *creator;
> > > struct work_struct destroyer;
> > > + struct syslog_ns *syslog;
> >
> > syslog_ns should be moved into nsproxy and unshared with a
> > separate clone(CLONE_SYSLOG);
>
> I agree. Keeping it in the user_namespace is strange. It should
> be in the nsproxy along with all of the other namespace pointers.
I won't argue on this, I put it in user_namespace as
serge proposed it at first and code implementation
was a test/trial to me.
Setting syslog in nsproxy is fine to me (seems
every body agree.. right?)
[...]
>
> Definitely. Actually, I think we can go one step further and say that
> passing syslog_ns directly to nsprintk() is wrong too. It's wrong
> because we only know the namespace that's relevant to the printk
> contents -- and that won't usually be a syslog_ns.
>
> Better to have the "find corresponding syslog_ns" logic inside
> nsprintk(). The great thing about doing it this way is if we
> ever decide to duplicate printk output to multiple containers it
> can be done inside nsprintk rather than doing a flag-day patch.
I tend to agree with you Matt.
I strongly disagree about what I understand
about Serge proposal to add a "new printk".
What is the purpose of printk?
- Report a system data to the acting authority.
Syslog cant be sent to:
HOST: syslog
CONT: syslog
CONT: + HOST: syslog (duplication)
Decision to duplicate syslog can be a printk
privilege, lets says "according message level".
Decision to send to HOST: or CONT: syslog
is depending execution context, which
can be found back within the printk function
itself (so no need to have ns_printk).
What is proposing Serge is to HARD CODE WITHIN kernel
if we call the genuine printk or ns_printk, which
is now a door wide open to coder interpretation ("is
printk message containerised or not", my coding decision
is as good as yours, and nobody will be satisfied).
My proposal is to say, if a ressource is containerized
it must be used in containerized context, this means
all printk are called within the context anyway.
What does that mean in real life?. lets call again the iptable
example.
We already have a HOST: iptables set AND a CONT: iptables
set. I have for my say, to keep consistency we MUST
execute CONT: iptables rules checking within the CONT: context
(which is not the case now... IMHO).
This approach is coherent, if a ressource (iptable,
network device, file system,...) is defined AND managed within
CONT: report must be done TO CONT: (period). Means
coding level need to take care ONLY about 'ressource'
ownership, if it is "own" by CONT: then access it in its
CONT: context.
Keep in mind, A fully containerized system can be managed
by someone with full privilege BUT NOT in charge of
the host itself (IE: without host access).
My proposal is a clear cut, if a ressource is containerized
report to CONT: (containerized) syslog... no question ask.
(sure enough printk could duplicate message to HOST:
my guess it won't be really needed in practical life,
but I could be wrong....)
--
A bientôt
==========================================================================
Jean-Marc Pigeon Internet: [email protected]
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";>
==========================================================================
_______________________________________________
Containers mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/containers
_______________________________________________
Devel mailing list
[email protected]
https://openvz.org/mailman/listinfo/devel
