Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751142AbdGNT30 (ORCPT <rfc822;w@1wt.eu>);
        Fri, 14 Jul 2017 15:29:26 -0400
Received: from imap.thunk.org ([74.207.234.97]:51266 "EHLO imap.thunk.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751056AbdGNT3Y (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 14 Jul 2017 15:29:24 -0400
Date: Fri, 14 Jul 2017 15:29:09 -0400
From: "Theodore Ts'o" <tytso@mit.edu>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
        Stefan Berger <stefanb@linux.vnet.ibm.com>,
        Mimi Zohar <zohar@us.ibm.com>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        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
Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces
Message-ID: <20170714192909.zoxnlm32nrxguqao@thunk.org>
Mail-Followup-To: Theodore Ts'o <tytso@mit.edu>,
        Mimi Zohar <zohar@linux.vnet.ibm.com>,
        "Serge E. Hallyn" <serge@hallyn.com>,
        Stefan Berger <stefanb@linux.vnet.ibm.com>,
        Mimi Zohar <zohar@us.ibm.com>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        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
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1500058090.3583.28.camel@linux.vnet.ibm.com>
User-Agent: NeoMutt/20170609 (1.8.3)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 633
Lines: 14

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.

					- Ted