From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751484AbbCSVmm (ORCPT ); Thu, 19 Mar 2015 17:42:42 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:54458 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751361AbbCSVmj (ORCPT ); Thu, 19 Mar 2015 17:42:39 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Ian Kent Cc: Kernel Mailing List , David Howells , Oleg Nesterov , Trond Myklebust , "J. Bruce Fields" , Benjamin Coddington , Al Viro , Jeff Layton References: <20150317022308.24592.35785.stgit@pluto.fritz.box> Date: Thu, 19 Mar 2015 16:38:51 -0500 In-Reply-To: <20150317022308.24592.35785.stgit@pluto.fritz.box> (Ian Kent's message of "Tue, 17 Mar 2015 10:44:49 +0800") Message-ID: <874mpghdlg.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX1+Q/nt7IZRjMRbnaWoMVYG4kS356V1/VLA= X-SA-Exim-Connect-IP: 70.59.163.10 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.7 XMSubLong Long Subject * 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 * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Ian Kent X-Spam-Relay-Country: X-Spam-Timing: total 406 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 7 (1.8%), b_tie_ro: 5.0 (1.2%), parse: 1.04 (0.3%), extract_message_metadata: 17 (4.3%), get_uri_detail_list: 2.4 (0.6%), tests_pri_-1000: 7 (1.6%), tests_pri_-950: 1.57 (0.4%), tests_pri_-900: 1.40 (0.3%), tests_pri_-400: 32 (7.9%), check_bayes: 31 (7.6%), b_tokenize: 9 (2.3%), b_tok_get_all: 9 (2.3%), b_comp_prob: 2.1 (0.5%), b_tok_touch_all: 4.3 (1.1%), b_finish: 0.61 (0.2%), tests_pri_0: 328 (80.9%), tests_pri_500: 6 (1.4%), rewrite_mail: 0.00 (0.0%) Subject: Re: [RFC PATCH v4 00/12] Second attempt at contained helper execution 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 Ian Kent writes: > Here is another update to the attempt at contained helper execution. > > The main change is I've tried to incorporate Oleg's suggestions > of directly constructing the namespaces rather than using the > open/setns approach and the addition of a namespace hash store. > > I'm not particularly happy with this so far as there are a bunch > of ref counted objects and I've almost certainly got that wrong. > But also there are object lifetime problems, some I'm aware of > and for sure others I'm not. Also there is the integrity of the > thread runner process. I haven't performed a double fork on thread > execution, it might be painful to implement, so the thread runner > might end up with the wrong namespace setup if an error occurs. > > Anyway, I've decided to stop spinning my wheels with this and > post an update in the hope that others can offer suggestions to > help and, of course, point out things I've missed. > > The other change has been to the nfs and KEYS patches. > I've introduced the ability to get a token that can be used to > save namespace information for later execution and I've attempted > to use that for persistent namespace execution, as was discussed > previously. > > I'm not at all sure I've done this in a sensible way but the > token does need to be accessible at helper execution time which > is why I've done it this way. > > I definitely need advice here too. As far as I can tell this patchset continues to be broken for ignoring my earlier advice. This patchset provides an escape from cgroup, lsm, rlimit, and seccomp policy. This patchset does not appear particularly nice in how it uses namespaces. The only safe and sane way to do this is to have a kernel thread with all of the proper attributes configured waiting around ready to start the user mode helper. The problem you are trying to solve is so hard that we totally failed to solve it outside of the container case. Which is why we have kthreadd. I will be very surprised if you can figure out how to cleanly solve the problem the way you are attacking it. Eric