Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758009AbcCUVei (ORCPT ); Mon, 21 Mar 2016 17:34:38 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:52180 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751159AbcCUVeg (ORCPT ); Mon, 21 Mar 2016 17:34:36 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Zhao Lei Cc: , , "'Mateusz Guzik'" , "'Kamezawa Hiroyuki'" References: <77053bb2bdd21489e09b6ef362044d283e1ba12b.1458305141.git.zhaolei@cn.fujitsu.com> <87twk0tlok.fsf@x220.int.ebiederm.org> <00fa01d18341$986e1880$c94a4980$@cn.fujitsu.com> <87shzkqmc8.fsf@x220.int.ebiederm.org> <00fb01d18359$b99df580$2cd9e080$@cn.fujitsu.com> Date: Mon, 21 Mar 2016 16:24:33 -0500 In-Reply-To: <00fb01d18359$b99df580$2cd9e080$@cn.fujitsu.com> (Zhao Lei's message of "Mon, 21 Mar 2016 18:09:15 +0800") Message-ID: <878u1bo772.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX18J71WAwM6o+qBepwxcAD8925UJ8ykgVWQ= X-SA-Exim-Connect-IP: 67.3.249.252 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa03 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Zhao Lei X-Spam-Relay-Country: X-Spam-Timing: total 635 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 13 (2.0%), b_tie_ro: 11 (1.8%), parse: 1.28 (0.2%), extract_message_metadata: 30 (4.8%), get_uri_detail_list: 2.9 (0.5%), tests_pri_-1000: 5 (0.8%), tests_pri_-950: 1.96 (0.3%), tests_pri_-900: 1.59 (0.2%), tests_pri_-400: 33 (5.1%), check_bayes: 31 (4.8%), b_tokenize: 11 (1.7%), b_tok_get_all: 7 (1.1%), b_comp_prob: 4.3 (0.7%), b_tok_touch_all: 3.0 (0.5%), b_finish: 0.87 (0.1%), tests_pri_0: 439 (69.1%), check_dkim_signature: 0.81 (0.1%), check_dkim_adsp: 15 (2.3%), tests_pri_500: 105 (16.6%), poll_dns_idle: 96 (15.1%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH v2 3/3] Make core_pattern support namespace X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1775 Lines: 43 Zhao Lei 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. Eric