Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752040AbcLEPgI (ORCPT ); Mon, 5 Dec 2016 10:36:08 -0500 Received: from mail-oi0-f65.google.com ([209.85.218.65]:34777 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751168AbcLEPgE (ORCPT ); Mon, 5 Dec 2016 10:36:04 -0500 MIME-Version: 1.0 X-Originating-IP: [217.173.44.24] In-Reply-To: <20161205151933.GA17517@fieldses.org> References: <5a6862bd-924d-25e4-2a8e-ba4f51e66604@web.de> <20161205151933.GA17517@fieldses.org> From: Miklos Szeredi Date: Mon, 5 Dec 2016 16:36:03 +0100 Message-ID: Subject: Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir To: "J. Bruce Fields" Cc: Patrick Plagwitz , "linux-unionfs@vger.kernel.org" , Linux NFS list , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andreas Gruenbacher Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1665 Lines: 45 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? >> 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? > algorithm, and lossy (in the NFSv4->POSIX direction). The client > developers have been understandably reluctant to have anything to do > with it. > > So, I think listxattr should omit system.nfs4_acl, and attempts to > set/get the attribute should error out. The same should apply to any > "system." attribute not supported by both filesystems, I think? Basically that's what happens now. The problem is that nfsv4 mounts seem always have these xattrs, even when the exported fs doesn't have anything. We could do the copy up even if the NFS4->POSIX translation was possible (which is the case with POSIX ACL translated by knfsd). We'd just get back the original ACL, so that's OK. NFS is only supported as lower (read-only) layer, so we don't care about changing the ACL on the server. Thanks, Miklos