public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Zhao Lei <zhaolei@cn.fujitsu.com>
To: "'Eric W. Biederman'" <ebiederm@xmission.com>
Cc: <linux-kernel@vger.kernel.org>,
	<containers@lists.linux-foundation.org>,
	"'Mateusz Guzik'" <mguzik@redhat.com>,
	"'Kamezawa Hiroyuki'" <kamezawa.hiroyu@jp.fujitsu.com>
Subject: RE: [PATCH v2 3/3] Make core_pattern support namespace
Date: Tue, 22 Mar 2016 09:38:06 +0800	[thread overview]
Message-ID: <010001d183db$7c0ae3e0$7420aba0$@cn.fujitsu.com> (raw)
In-Reply-To: <878u1bo772.fsf@x220.int.ebiederm.org>

Hi, Eric

> -----Original Message-----
> From: Eric W. Biederman [mailto:ebiederm@xmission.com]
> Sent: Tuesday, March 22, 2016 5:25 AM
> To: Zhao Lei <zhaolei@cn.fujitsu.com>
> Cc: linux-kernel@vger.kernel.org; containers@lists.linux-foundation.org;
> 'Mateusz Guzik' <mguzik@redhat.com>; 'Kamezawa Hiroyuki'
> <kamezawa.hiroyu@jp.fujitsu.com>
> Subject: Re: [PATCH v2 3/3] Make core_pattern support namespace
> 
> Zhao Lei <zhaolei@cn.fujitsu.com> writes:
> 
> > Hi, Eric
> >
> >> -----Original Message-----
> >> From: Eric W. Biederman [mailto:ebiederm@xmission.com]
> 
> > Let me make a summarize:
> > You think this way is not acceptable, because the pipe program is running
> > in the panic-process's namespace context.
> 
> Actually my view is that your patchset is not acceptable because it
> is implemented in a way that is not backwards compatible (AKA it can
> break existing configurations that remain unchanged) and your
> implementation does not appear in the least safe from malicious users.
> 
> There is also a problem that your patchset is simply buggy for what it
> tries to implement, as using pid_ns_for_children and the multiple kbuild
> robot emails testifies.
> 
> > And in my view, a pipe program in the host's top level namespace is also
> > a problem.
> >
> > Let us think a container, to make it act as a real machine, when a program
> > panic, linux kernel should dump it into the container's filesystem.
> >
> > For the kernel, to keep the current way of forking pipe program by kthread,
> > just let the pipe thread running in the container's namespace, instead the
> host,
> > may solve the problem in current kernel.
> >
> > What is your opinion?
> >
> > Btw, this patch is trying to solve the problem descripted in thread named:
> > "piping core dump to a program escapes container" in
> >
> http://lists.linuxfoundation.org/pipermail/containers/2015-December/036476.
> html
> > Maybe using a userspace tool can make container dump to anywhere,
> > but for kernel ifself, it is better to solve above problem if we can.
> 
> I think it would be great to find a way to run a core dump helper and
> otherwise allow setting the core dump pattern in a container in a way
> that is safe from malicious users and does not break existing setups.
> 
So, there is following problem:
1: safe from malicious users
  We can try to find a way to fork process which have no relationship
  with the panic process.
2: Bug in patch
  It can be fixed, but I'd rather get a conclusion of this discussion
  before fix.
3: Backwards compatible
  It maybe the biggest problem in discussion, this patch is used to let
  container dump files into container, it is different with current action.
  Before patch:
    File type dump_pattern: dump to container
    Pipe type dump_pattern: dump to host
  After patch:
    File type dump_pattern: dump to container
    Pipe type dump_pattern: dump to container
  The second design seems better but not compatible with current kernel,
  but this patch can not fix to keep compatible because it is the patch's
  function.
  Maybe we can make some workagound, as:
  a. Add a kernel config to let the old style as default.
  b. keep old style, and add "||" for core_pattern, as
    echo "|| /root/container_dumper" >/proc/sys/kernel/core_pattern
    to dump to container.

  What is your opinion about it?

Thanks
Zhaolei

  reply	other threads:[~2016-03-22  1:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-18 12:48 [PATCH v2 0/3] Make core_pattern support namespace Zhao Lei
2016-03-18 12:48 ` [PATCH v2 1/3] Make _do_fork support return to caller's code Zhao Lei
2016-03-18 12:48 ` [PATCH v2 2/3] Run dump pipe in container's namespace Zhao Lei
2016-03-18 14:06   ` kbuild test robot
2016-03-18 12:48 ` [PATCH v2 3/3] Make core_pattern support namespace Zhao Lei
2016-03-21  6:00   ` Eric W. Biederman
2016-03-21  7:16     ` Zhao Lei
2016-03-21  8:14       ` Eric W. Biederman
2016-03-21 10:09         ` Zhao Lei
2016-03-21 21:24           ` Eric W. Biederman
2016-03-22  1:38             ` Zhao Lei [this message]
2016-03-22 22:42               ` Eric W. Biederman
2016-03-23 11:58                 ` Zhao Lei
2016-03-23 19:54                   ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='010001d183db$7c0ae3e0$7420aba0$@cn.fujitsu.com' \
    --to=zhaolei@cn.fujitsu.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mguzik@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox