Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751977AbdGLXVn (ORCPT ); Wed, 12 Jul 2017 19:21:43 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:46292 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751906AbdGLXVm (ORCPT ); Wed, 12 Jul 2017 19:21:42 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: "Serge E. Hallyn" Cc: Stefan Berger , containers@lists.linux-foundation.org, lkp@01.org, linux-kernel@vger.kernel.org, zohar@linux.vnet.ibm.com, tycho@docker.com, James.Bottomley@HansenPartnership.com, vgoyal@redhat.com, christian.brauner@mailbox.org, amir73il@gmail.com, linux-security-module@vger.kernel.org, casey@schaufler-ca.com References: <1499785511-17192-1-git-send-email-stefanb@linux.vnet.ibm.com> <1499785511-17192-2-git-send-email-stefanb@linux.vnet.ibm.com> <87mv89iy7q.fsf@xmission.com> <20170712170346.GA17974@mail.hallyn.com> Date: Wed, 12 Jul 2017 18:13:41 -0500 In-Reply-To: <20170712170346.GA17974@mail.hallyn.com> (Serge E. Hallyn's message of "Wed, 12 Jul 2017 12:03:46 -0500") Message-ID: <877ezdgsey.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1dVQwm-00019J-Sz;;;mid=<877ezdgsey.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=67.3.213.87;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/JEGuipqnGc9AdT68/FGzqwGZG88+z058= X-SA-Exim-Connect-IP: 67.3.213.87 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.4998] * -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: ;"Serge E. Hallyn" X-Spam-Relay-Country: X-Spam-Timing: total 5681 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 2.5 (0.0%), b_tie_ro: 1.76 (0.0%), parse: 0.75 (0.0%), extract_message_metadata: 14 (0.2%), get_uri_detail_list: 1.74 (0.0%), tests_pri_-1000: 7 (0.1%), tests_pri_-950: 1.13 (0.0%), tests_pri_-900: 0.96 (0.0%), tests_pri_-400: 24 (0.4%), check_bayes: 23 (0.4%), b_tokenize: 7 (0.1%), b_tok_get_all: 9 (0.2%), b_comp_prob: 2.4 (0.0%), b_tok_touch_all: 2.9 (0.1%), b_finish: 0.59 (0.0%), tests_pri_0: 170 (3.0%), check_dkim_signature: 0.46 (0.0%), check_dkim_adsp: 2.7 (0.0%), tests_pri_500: 5459 (96.1%), poll_dns_idle: 5451 (96.0%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1775 Lines: 46 "Serge E. Hallyn" writes: > Quoting Eric W. Biederman (ebiederm@xmission.com): >> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes: >> > Signed-off-by: Stefan Berger >> > Signed-off-by: Serge Hallyn >> > Reviewed-by: Serge Hallyn >> >> It doesn't look like this is coming through Serge so I don't see how >> the Signed-off-by tag is legtimate. > > This is mostly explained by the fact that there have been a *lot* of > changes, many of them discussed in private emails. > >> >From the replies to this it doesn't look like Serge has reviewed this >> version either. >> >> I am disappointed that all of my concerns about technical feasibility >> remain unaddressed. > > Can you re-state those, or give a link to them? Well I only posted about one substantive comment on the last round so it should be easy to find that said. The big question is how does this intereact with filesystems xattr implementations? There is the potential that we create many more security xattrs this way. How does that scale? With more names etc. What happens if we have one xattr per uid for 1000+ uids? How does this interact with filesystems optimization of xattr names? For some filesystems they optmize the xattr names, and don't store the entire thing. > I'd really like to get to a point where unprivileged containers can start > using filecaps - at this point if that means having an extra temporary > file format based on my earlier patchset while we hash this out, that > actually seems worthwhile. But it would of course be ideal if we could > do the name based caps right in the first place. This whole new version has set my review back to square one unfortunately. Eric