Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753256AbcLEW66 (ORCPT ); Mon, 5 Dec 2016 17:58:58 -0500 Received: from mout.web.de ([217.72.192.78]:64597 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751998AbcLEW6y (ORCPT ); Mon, 5 Dec 2016 17:58:54 -0500 Subject: Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir To: =?UTF-8?Q?Andreas_Gr=c3=bcnbacher?= , "J. Bruce Fields" References: <5a6862bd-924d-25e4-2a8e-ba4f51e66604@web.de> <20161205151933.GA17517@fieldses.org> <20161205162559.GB17517@fieldses.org> Cc: Miklos Szeredi , "linux-unionfs@vger.kernel.org" , Linux NFS list , Linux FS-devel Mailing List , Linux Kernel Mailing List , Andreas Gruenbacher From: Patrick Plagwitz Message-ID: <266c571f-e4e2-7c61-5ee2-8ece0c2d06e9@web.de> Date: Mon, 5 Dec 2016 23:58:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:KhpiHSLKICrevb9KpFOYJA9nLfl/w0UCxsBzeb+m8s+igBAdfbQ 39N2bO/liLQp8VBOIJfKBg0F6Z4rPNrxzSmXyAWBjy4FgOC/k0nMspf1AV6kbbgwpCODh7q qL5M1GW9aOcjgL6c+HT4r1/puCdztlsEDZ0sAQzbD/mlh7yCZE+3WxYi5Ahe+NUPRghSWRQ xQ3ZgFlrW2+b7ZFC2jIJA== X-UI-Out-Filterresults: notjunk:1;V01:K0:yvAV1OmVKds=:NdKvsjSCPUUDY8pR3IGVHP Y0X6MNb0WOCAFRm7D63nnlZV2q5LpHXe5iWaoDN2b2ki59w7GO8TrzlREUTdGBFBrDthSobHQ sVg8P8vmDRbL2imo8WlP54aKZB1HgfTcq018d82D2KsHK9Da/zbEmQxx0fGocOokvKHmSwRnI BQyKA1Cw4y4+Jl7m/7qEbaB8lOpcVW0sGlhOMM6Fw/KW/TyL+/c1v+6Xv5tJoylqbd32WnFb2 DpeWCeBBtSNzdTBvaSEWf5r23s2ar7w+Z4ePWFSQZ76FAOa2xAzTAdmtBOgDSS9DFn5YhscmD urGtyzNzjiskDEJXrnXQCvlUW6nWcZOieZCIHPEshkc3+/OaCJ2gSRHiz8n5rgQC1TNwzeSPl 1COwAfg594AK5IzWBk9zEwGDWRkrOs0MX+WH4EwrVUEcEPav+AJF7Em90dRCelMDsqJxXYZas dBbCrGupTnts9djp8kq/u2pkSE736hIhQszhMv839zCYiHSuM/09KOQhQC03W3Per9ErVh9qw 8uYR0zekv2xHg9nG40ze5GZavtOvSTDz06y8Pq9bDrn6WlOJGTE+vVbTyD5kWVJMtL4iLnuRn GW2e1MMxW2L94t2EXP2NWEY8coTPueQSg3g9m1oj4IkMNqBUTK1Ou37Uok1FTYmePHSq7ECIr tIkLKMkbZn05VwNWasX/HLUDqXEO0MNgXoxfbWpUzD8iXLmEJwDyamKAhY0Jl1+Nv45UBLCY3 BelBbXY073xfGwhPMxKsHDP93Dfl1gwTjsztQ0kR3SmNUiswH4r1mwvMt70U0VNhqSH9gHZih Mw8pXlT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2956 Lines: 64 On 12/05/2016 08:37 PM, Andreas Grünbacher wrote: > 2016-12-05 17:25 GMT+01:00 J. Bruce Fields : >> On Mon, Dec 05, 2016 at 04:36:03PM +0100, Miklos Szeredi wrote: >>> On Mon, Dec 5, 2016 at 4:19 PM, J. Bruce Fields wrote: >>>>> Can NFS people comment on this? Where does the nfs4_acl come from? >>>> >>>> This is the interface the NFS client provides for applications to modify >>>> NFSv4 ACLs on servers that support them. >>> >>> Fine, but why are we seeing this xattr on exports where no xattrs are >>> set on the exported fs? >> >> I don't know. I took another look at the original patch and don't see >> any details on the server setup: which server is it (knfsd, ganesha, >> netapp, ...)? How is it configured? >> >>>>> What can overlayfs do if it's a non-empty ACL? >>>> >>>> As little as possible. You can't copy it up, can you? So any attempt >>>> to support it is going to be incomplete. >>> >>> Right. >>> >>>> >>>>> Does knfsd translate posix ACL into NFS acl? If so, we can translate >>>>> back. Should we do a generic POSIX<->NFS acl translator? >>>> >>>> knsd does translate between POSIX and NFSv4 ACLs. It's a complicated >>> >>> This does explain the nfs4_acl xattr on the client. Question: if it's >>> empty, why have it at all? >> >> I'm honestly not sure what's going on there. I'd be curious to see a >> network trace if possible. > > I do see "system.nfs4_acl" attributes on knfsd exported filesystems > that support POSIX ACLs (for ext4: "mount -o acl"). For exported > filesystem that don't support POSIX ACLs (ext4: mount -o noacl), that > attribute is missing. The attribute shouldn't be empty though; when > the file has no real ACL, "system.nfs4_acl" represents the file mode > permissions. The "system.nfs4_acl" attribute exposes the information > on the wire; there is no resonable way to translate that into an ACL > on another filesystem, really. > > Patrick, what does 'getfattr -m- -d /nfs/file' give you? > getfattr -m - -d nfs/folder -e text gives # file: nfs/folder/ system.nfs4_acl="\000\000\000^C\000\000\000\000\000\000\000\000\000^V^A\000\000\000^FOWNER@\000\000\000\000\000\000\000\000\000\000\000^R\000\000\000\000^FGROUP@\000\000\000\000\000\000\000\000\000\000\000^R\000\000\000\000 EVERYONE@\000\000" Those are 80 bytes. I checked again and vfs_getxattr indeed returns size=80. It just looked empty because the first byte is 0... Ok, so nfs4_acl is not empty after all and checking *value == 0 does not tell if there are actually ACLs present or not, sorry for the confusion. You are right, when I mount the exported fs with noacl the problem goes away. You already helped me there, thanks. Still, I think there should be a way to copy up files that actually have no ACLs since acl is often the default for ext4 mounts and giving an "Operation not supported" for random open(2)s is not a very good way to convey what's going on.