Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp7464575yba; Thu, 2 May 2019 10:16:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqzC1NPeTdEKxDFY+cprbfBogMcf58cG6jD7nX75C3+MTRSmpP8pH9c5UnRrYZU/2KEIn79v X-Received: by 2002:a63:3746:: with SMTP id g6mr5167323pgn.422.1556817392460; Thu, 02 May 2019 10:16:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556817392; cv=none; d=google.com; s=arc-20160816; b=L4RDnZjdP2iBPb5HyZksQMaZo/+wUKBTkR0LEogeZUq84RYyHk/yEKUTfqt6sfVuph 1VNW8D89tqzqE43iMdLaSdNZmheJnJ4t9Bf+kwg0g2zN+EudIL+GZtsOuKS/VaNID8vL y9/KgHhdNIYvKwwDN1vNRE4zuiGcyRxbmH0MMaM/G6SfceUEVB5O3SCXrvnTKdmAoHNv HVL92iKDjxToxSzc0MRoQCoOiTpRLTYx8nzNht2mceL2P3Fl9CFOas9As2P1a2o/Z26N KTb6aOBAyK0v9tu5wvku50HTVvVck9r7FYMzfyOGoGG+4F6qIZgMKD9tOXm15jB7kn8N pKeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=K2dZmGQH01fkyFlwuSa8Q6Q3m6dQIom7ys/1MfsE7Qc=; b=yeF3TqXX41bi5kgqK48uZ9qA95QG+Xj2X11ve8fAVHRte/X30teJWi1c6+VCzV56pR 53r9HrKr40clHqpw+pHVEADVk9Ul+igZquW7xiUnZFl/hXBQ4t2nURJdahor0E6JRz7U z9jk84hsRhOX/rovng+SPXjiFo0oOoNCcrZ9448l3S94CfyhOdyO1lOP1AMrMujoF0IE 58Ztp6EAsdko4zhmk8Ji2ZoGneazh9ZgBFTdLzzExS01wkjRTERzr4wB0qzjg/RN4q8H aqGI21NicMS85Svp6YLpGOJH/OYav/rhW6ZtOFVHp06uY2sOAv/tFgVGduhn+61UHt/I t8IQ== ARC-Authentication-Results: i=1; mx.google.com; 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 w125si47771766pfw.137.2019.05.02.10.16.09; Thu, 02 May 2019 10:16:32 -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; 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 S1726304AbfEBRQE (ORCPT + 99 others); Thu, 2 May 2019 13:16:04 -0400 Received: from fieldses.org ([173.255.197.46]:52264 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725951AbfEBRQE (ORCPT ); Thu, 2 May 2019 13:16:04 -0400 Received: by fieldses.org (Postfix, from userid 2815) id 9E9321BE3; Thu, 2 May 2019 13:16:03 -0400 (EDT) Date: Thu, 2 May 2019 13:16:03 -0400 From: "J. Bruce Fields" To: Andreas =?utf-8?Q?Gr=C3=BCnbacher?= Cc: Miklos Szeredi , Andreas Gruenbacher , NeilBrown , Amir Goldstein , Patrick Plagwitz , "linux-unionfs@vger.kernel.org" , Linux NFS list , Linux FS-devel Mailing List , Linux Kernel Mailing List Subject: Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir Message-ID: <20190502171603.GA1778@fieldses.org> References: <20161206185806.GC31197@fieldses.org> <87bm0l4nra.fsf@notabene.neil.brown.name> <875zqt4igg.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Thu, May 02, 2019 at 05:08:14PM +0200, Andreas Grünbacher wrote: > You'll still see permissions that differ from what the filesystem > enforces, and copy-up would change that behavior. That's always true, and this issue isn't really specific to NFSv4 ACLs (or ACLs at all), it already exists with just mode bits. The client doesn't know how principals may be mapped on the server, doesn't know group membership, etc. That's the usual model, anyway. Permissions are almost entirely the server's responsibility, and we just provide a few attributes to set/get those server-side permissions. The overlayfs/NFS case is different, I think: the nfs filesystem may be just a static read-only template for a filesystem that's only ever used by clients, and for all I know maybe permissions should only be interpreted on the client side in that case. --b.