Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751205AbdGNToE (ORCPT ); Fri, 14 Jul 2017 15:44:04 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:37222 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751061AbdGNToB (ORCPT ); Fri, 14 Jul 2017 15:44:01 -0400 Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces From: Mimi Zohar To: "Theodore Ts'o" Cc: "Serge E. Hallyn" , Stefan Berger , Mimi Zohar , "Eric W. Biederman" , containers@lists.linux-foundation.org, lkp@01.org, linux-kernel@vger.kernel.org, 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 Date: Fri, 14 Jul 2017 15:43:46 -0400 In-Reply-To: <20170714192909.zoxnlm32nrxguqao@thunk.org> References: <87k23cb6os.fsf@xmission.com> <847ccb2a-30c0-a94c-df6f-091c8901eaa0@linux.vnet.ibm.com> <87bmoo8bxb.fsf@xmission.com> <9a3010e5-ca2b-5e7a-656b-fcc14f7bec4e@linux.vnet.ibm.com> <87h8yf7szd.fsf@xmission.com> <65dbe654-0d99-03fa-c838-5a726b462826@linux.vnet.ibm.com> <20170714133437.GA16737@mail.hallyn.com> <596f808b-e21d-8296-5fef-23c1ce7ab778@linux.vnet.ibm.com> <20170714173556.GA19669@mail.hallyn.com> <1500058090.3583.28.camel@linux.vnet.ibm.com> <20170714192909.zoxnlm32nrxguqao@thunk.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable x-cbid: 17071419-0044-0000-0000-0000027FC74B X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17071419-0045-0000-0000-000007107CE2 Message-Id: <1500061426.3583.65.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-14_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707140312 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1106 Lines: 22 On Fri, 2017-07-14 at 15:29 -0400, Theodore Ts'o wrote: > On Fri, Jul 14, 2017 at 02:48:10PM -0400, Mimi Zohar wrote: > > > > If I'm understanding the discussion correctly, this isn't an issue for > > layered copy on write filesystems, as each fs layer could have it's > > own set of xattrs.  The underlying and layered xattrs should be able > > to co-exist.  Use the layered xattr if it exists, but fall back to > > using the underlying xattr if it doesn't. > > Note that this assumes that it is possible to "copy up" the xattrs > without necessarily "copying up" all of the data blocks. This might > be true for some layers, but I don't believe it is currently true for > overlayfs, for example. Ok, so for the use case scneario where the container owner is willing to use the public key distributed with the files, then only those files that are new or modified in the overlay would need to be signed with a key local to the overlay.  In the worst case scenario, where the container owner is only willing to trust their own public key, I guess we can live with having to copy up the files. Mimi