Return-Path: Received: from fieldses.org ([173.255.197.46]:54454 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932451AbeEaApy (ORCPT ); Wed, 30 May 2018 20:45:54 -0400 Date: Wed, 30 May 2018 20:45:54 -0400 To: Goldwyn Rodrigues Cc: Trond Myklebust , "linux-nfs@vger.kernel.org" , "linux-unionfs@vger.kernel.org" Subject: Re: nfs4_acl restricts copy_up in overlayfs Message-ID: <20180531004554.GA29116@fieldses.org> References: <2cf94c6b-e819-79af-4ac9-3b19d26dc6d9@suse.de> <75266c983a03f6dbfd5d1a39c94fa6d56a1a8a22.camel@hammerspace.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: From: bfields@fieldses.org (J. Bruce Fields) Sender: linux-nfs-owner@vger.kernel.org List-ID: On Wed, May 30, 2018 at 05:33:11AM -0500, Goldwyn Rodrigues wrote: > I am not trying to override the security. I am trying to detect > duplication of security information. The common case of NFS > communication does not require the additional security parameters > (doesn't mean it is not required). So my question is: is it possible to > detect at the client that nfs4_acl is a duplicate of information which > can be and is represented by inode alone. If yes, can it be suppressed > by the client. No, that's not possible. The user's identity could be mapped in various ways. You've got no way to know whether root squashing is in effect, for example. Or to know what the user@EXAMPLE.COM krb5 identity that you're running as might map to on the server. So it's hard to even tell whether a given user matches the file's owner or group. So even the mode bits are kind of meaningless to the client. --b.