Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6831765yba; Wed, 1 May 2019 22:08:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqwg0h+SQ4IjJeqPaWkEA/YawpCF88oCwdmjZUy2eqRJoi5W5gmI3JJw2v+WH48byY6CeH4t X-Received: by 2002:a62:6807:: with SMTP id d7mr1854645pfc.75.1556773736330; Wed, 01 May 2019 22:08:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556773736; cv=none; d=google.com; s=arc-20160816; b=F8jQqdir/Uw5goRaigvzIfzccQUvaBYsyHWZcUrCJr2klLIiIvLeag2sJZ0CAzmZLF TJnWwamiOGOKYb98QLAnrq2cAzv9ZIUd/o0npHkhP7yp/+3xOUwZZmD22Q7l74Qf19Rs /xwHQfLyfEf3KfLT0nFyosFbx6wbywxBB7RqHVnA63NNMsKXYKt2Mrgh6Imw3QBJBWuI 9iDVp86ckRCd0RINUujSwy4M6sEmu6nbOhTcEmmpbpJQNo9wvUCvOoae6GeD19RRmvwL lAGnMebckUetBkhQVuLLCjGfeWwMtGpUu3fFi+XydXYNlsp5bRJsomKYEe52y72gS/x2 wfkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=Fudg6aBxe0TkPNIqYA88Y89agb4T2MW29SCxmEQ3FDg=; b=SGseCbKkK+JuJvg+DJEyKjZevfw74Svi8dtzsQng6KUHJQjvXBwmQrQL3s0oriyrgW 7ZcKjzI6NpP8CF+OybuZEIxJK+Arw7Z73kDrBcILHHs8im8mBvjRXrifuXzdCRYIcKKb LCn4iwiS6BNVHiwk3HD6DdSOSvcOGH7XvHPmwak2FVha1uuEgse12JDbBUFFbHDrEOHV CHvjVufFSdauaf+cGgBVyf1gKEhF82WGkZKGCvNAONxNxNu0gYVZJCM42d+GjaxX4o8H CjJ6wl9Cwdbym3AFPrzizRNWIsxFEvbpCHJ0bJBQKQU9hf8PLM9IOgiBnIR5tm7aImc7 DBYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=QtiQDJhM; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t14si20108184pgg.32.2019.05.01.22.08.28; Wed, 01 May 2019 22:08:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=QtiQDJhM; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725763AbfEBFI1 (ORCPT + 99 others); Thu, 2 May 2019 01:08:27 -0400 Received: from merlin.infradead.org ([205.233.59.134]:50718 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725616AbfEBFI1 (ORCPT ); Thu, 2 May 2019 01:08:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Fudg6aBxe0TkPNIqYA88Y89agb4T2MW29SCxmEQ3FDg=; b=QtiQDJhMITB8z86q7y2rFHLizw A0n7Ay+W13jFlrAu5jmXGN4yKvKjZQkip/Al1Dj2gLr1dMSxDf6ckHScQ3SFxcYdmxVmCUu0yywtu C6oru7DSuxU41Q6vaaEvQKdWQ4Z5WI4LiMKKeU/N/4Xqdguq1hvSNjl7pXg6QTqq/NIW4zIkxKjWJ xdDrHL1MdmTrauH/fAxyax92MpcYlnZrjmYaEXrV0PVn39KohTnHNl3c0IHSDVBJkwX43bqMYdi1Q WiyyznShpO4/IGLm/RXiUaspQ7bwkO35wthrNfb+Cr4qtlg9+PNy18wDkkC8Xm+SgjRUqx9BNqm3h M5pbJwzg==; Received: from static-50-53-52-16.bvtn.or.frontiernet.net ([50.53.52.16] helo=dragon.dunlab) by merlin.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1hM3xG-0004oT-En; Thu, 02 May 2019 05:08:22 +0000 Subject: Re: [PATCH] OVL: add honoracl=off mount option. To: NeilBrown , "J. Bruce Fields" , Andreas Gruenbacher Cc: Miklos Szeredi , =?UTF-8?Q?Andreas_Gr=c3=bcnbacher?= , Patrick Plagwitz , "linux-unionfs@vger.kernel.org" , Linux NFS list , Linux FS-devel Mailing List , Linux Kernel Mailing List References: <20161205151933.GA17517@fieldses.org> <20161205162559.GB17517@fieldses.org> <266c571f-e4e2-7c61-5ee2-8ece0c2d06e9@web.de> <20161206185806.GC31197@fieldses.org> <87bm0l4nra.fsf@notabene.neil.brown.name> <8736lx4goa.fsf@notabene.neil.brown.name> From: Randy Dunlap Message-ID: <9ada42cb-8783-49bb-fd0d-31e7fb7dacf4@infradead.org> Date: Wed, 1 May 2019 22:08:19 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <8736lx4goa.fsf@notabene.neil.brown.name> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org Hi Neil, On 5/1/19 9:35 PM, NeilBrown wrote: > > If the upper and lower layers use incompatible ACL formats, it is not > possible to copy the ACL xttr from one to the other, so overlayfs attr (?) > cannot work with them. > This happens particularly with NFSv4 which uses system.nfs4_acl, and > ext4 which uses system.posix_acl_access. > > If all ACLs actually make to Unix permissions, then there is no need map (?) > to copy up the ACLs, but overlayfs cannot determine this. > > So allow the sysadmin it assert that ACLs are not needed with a mount > option > honoracl=off > This causes the ACLs to not be copied, so filesystems with different > ACL formats can be overlaid together. > > Signed-off-by: NeilBrown > --- > Documentation/filesystems/overlayfs.txt | 24 ++++++++++++++++++++++++ > fs/overlayfs/copy_up.c | 9 +++++++-- > fs/overlayfs/dir.c | 2 +- > fs/overlayfs/overlayfs.h | 2 +- > fs/overlayfs/ovl_entry.h | 1 + > fs/overlayfs/super.c | 15 +++++++++++++++ > 6 files changed, 49 insertions(+), 4 deletions(-) > > diff --git a/Documentation/filesystems/overlayfs.txt b/Documentation/filesystems/overlayfs.txt > index eef7d9d259e8..7ad675940c93 100644 > --- a/Documentation/filesystems/overlayfs.txt > +++ b/Documentation/filesystems/overlayfs.txt > @@ -245,6 +245,30 @@ filesystem - future operations on the file are barely noticed by the > overlay filesystem (though an operation on the name of the file such as > rename or unlink will of course be noticed and handled). > > +ACL copy-up > +----------- > + > +When a file that only exists on the lower layer is modified it needs > +to be copied up to the upper layer. This means copying the metadata > +and (usually) the data (though see "Metadata only copy up" below). > +One part of the metadata can be problematic: the ACLs. > + > +Now all filesystems support ACLs, and when they do they don't all use Not > +the same format. A significant conflict appears between POSIX acls ACLs > +used on many local filesystems, and NFSv4 ACLs used with NFSv4. There These (or the) > +two formats are, in general, not inter-convertible. > + > +If a site only uses regular Unix permissions (Read, Write, eXecute by > +User, Group and Other), then as these permissions are compatible with > +all ACLs, there is no need to copy ACLs. overlayfs cannot determine > +if this is the case itself. > + > +For this reason, overlayfs supports a mount option "honoracl=off" > +which causes ACLs, any "system." extended attribute, on the lower > +layer to be ignored and, particularly, not copied to the upper later. > +This allows NFSv4 to be overlaid with a local filesystem, but should > +only be used if the only access controls used on the filesystem are > +Unix permission bits. > > Multiple lower layers > --------------------- -- ~Randy