Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp6388630ybe; Wed, 18 Sep 2019 02:39:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqxYTAa/21pMzKRFWAkPs0zC5TLuHhOb1OlsQoIuHf5ovZ4ifsSdu7gGEJlDyp6YHuTjiyqL X-Received: by 2002:a50:f789:: with SMTP id h9mr9268476edn.139.1568799542257; Wed, 18 Sep 2019 02:39:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568799542; cv=none; d=google.com; s=arc-20160816; b=cIgcjhhOJqQoWuyUGYIaA9k1uOas/NZf3t5Z0hAWgOcRjHCdcLh50Fzrs9TcXDmG4q 47Ec0kLdeU38xM21V82AkLk+5qnqSrmczhECAIxGwkrzv7h4lx/R5MWaRxFP03/AXI0v DPbL1AS+b1gf+4oMDDRRZjiEl1y5ES9kM2vPzVXS6/4pVGXS6HSwnSK6NgL+V9rCxbaU jfKK6FInWhqRwNc/8Nu9rRO4dvWgeC4FvrVlsS2pD257hVt06x4V3lfNGS2OVDGUD1D6 P6HsS/0BF5lZRodmmqfsoORfgAEM2VPiLPt/iNb3BXOE2lx9tJnbzotkgYhWuFI+XPSc g8+w== 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-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=6G/whdxwOVG2qxmcsy9XC+pDIIKNhBXnDvwIF4K/VBs=; b=zbZB7KEZczu4JekUDqvOeosUGLYdgw843NaFnLjnSJ56FyiZoBT8egxu3n/RFoDiij 88sT6U0vwhnQ80isk1ys62EfEKgpG8KwjM1+a6tEho6OdkxDeahgiRD3DPrUF12V5xAQ a/t1tDMu4iGaZS3gtm3Isd+8iV+2Mb7FicV6apGRhaS2EhtsMle7OJRbSIvTvcVI150H rsabpZZbDC+YhgQbNp4OKKlloA2iq5s+zNwWE3agO+9X7iemfVBrjgxqECQoCeJfTZNQ xqJynyKez3Aw3LghMsjPV7WSuqCl5z0mwMU4jzY5P9R41mxk8PX1Kt3cACaWJ5gp7ga9 36JA== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=kfWr8gWB; 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 l18si3149723edb.155.2019.09.18.02.38.27; Wed, 18 Sep 2019 02:39:02 -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=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=kfWr8gWB; 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 S1728427AbfIRJHh (ORCPT + 99 others); Wed, 18 Sep 2019 05:07:37 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:55590 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728278AbfIRJHh (ORCPT ); Wed, 18 Sep 2019 05:07:37 -0400 Received: by mail-wm1-f66.google.com with SMTP id a6so1623583wma.5 for ; Wed, 18 Sep 2019 02:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=6G/whdxwOVG2qxmcsy9XC+pDIIKNhBXnDvwIF4K/VBs=; b=kfWr8gWBYBcBGgcxeOud4gsGHHoCDZ+e2gVUoUqlrkYqpWgQKaJ78hHgXC3ilzVr0O +8pkEG8kqn4PpvoHDlJhIdgZOtD96xrMJPf5rxoAvthocW4621d3D9Qh5trYnLS5SZ1C BN08nY19kls8ugqtZhrEwO8LpHQ8mUyG2tZWI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=6G/whdxwOVG2qxmcsy9XC+pDIIKNhBXnDvwIF4K/VBs=; b=H6p9iWO11ld5v5o0cA1+YOPckUn0M6qWcoscALNELQWOCJQT4xxWNf8E1PNEnJIYQC YGWeXTfhpJYxVnENV7AuvsIxwb4yalNFBMe9Fkij9lqgC497viVUt+wKu/5+A8v6gklF kbZORSVT8lFLFkaFWGtj5+QfRp2kkELtp/niDTkXkTXg38vzQO/ozvX4gkon/fKqxIb5 XjtWbMYjjzfoEjbsSdo84ypYEJDyCWK4w9/GSuv9YnNrFF8eLfi98ljRO25VbbWSDCV3 qABCuXVVEk3FwCu42kg2Dc5A1uWN9EQGNsysKV3EXGzexoBN6AUcQeAtrTRumoTWQKWA gZ5w== X-Gm-Message-State: APjAAAUAP5P74LAHz/eAmImByMd0PSoNALyh3cOZnRpgh+uqZzp10JW2 7X9QZQsDECnUKdN2KuPUfutufQ== X-Received: by 2002:a7b:c1cc:: with SMTP id a12mr1816647wmj.73.1568797655318; Wed, 18 Sep 2019 02:07:35 -0700 (PDT) Received: from miu.piliscsaba.redhat.com (catv-212-96-48-140.catv.broadband.hu. [212.96.48.140]) by smtp.gmail.com with ESMTPSA id q124sm2478546wma.5.2019.09.18.02.07.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Sep 2019 02:07:34 -0700 (PDT) Date: Wed, 18 Sep 2019 11:07:31 +0200 From: Miklos Szeredi To: "J. Bruce Fields" Cc: NeilBrown , Andreas Gruenbacher , Andreas =?utf-8?Q?Gr=C3=BCnbacher?= , Patrick Plagwitz , "linux-unionfs@vger.kernel.org" , Linux NFS list , Linux FS-devel Mailing List , Linux Kernel Mailing List , Thomas Lange Subject: Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir Message-ID: <20190918090731.GB19549@miu.piliscsaba.redhat.com> References: <266c571f-e4e2-7c61-5ee2-8ece0c2d06e9@web.de> <20161206185806.GC31197@fieldses.org> <87bm0l4nra.fsf@notabene.neil.brown.name> <20190503153531.GJ12608@fieldses.org> <87woj3157p.fsf@notabene.neil.brown.name> <20190510200941.GB5349@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190510200941.GB5349@fieldses.org> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Fri, May 10, 2019 at 04:09:41PM -0400, J. Bruce Fields wrote: > On Tue, May 07, 2019 at 10:24:58AM +1000, NeilBrown wrote: > > Interesting perspective .... though doesn't NFSv4 explicitly allow > > client-side ACL enforcement in the case of delegations? > > Not really. What you're probably thinking of is the single ACE that the > server can return on granting a delegation, that tells the client it can > skip the ACCESS check for users matching that ACE. It's unclear how > useful that is. It's currently unused by the Linux client and server. > > > Not sure how relevant that is.... > > > > It seems to me we have two options: > > 1/ declare the NFSv4 doesn't work as a lower layer for overlayfs and > > recommend people use NFSv3, or > > 2/ Modify overlayfs to work with NFSv4 by ignoring nfsv4 ACLs either > > 2a/ always - and ignore all other acls and probably all system. xattrs, > > or > > 2b/ based on a mount option that might be > > 2bi/ general "noacl" or might be > > 2bii/ explicit "noxattr=system.nfs4acl" > > > > I think that continuing to discuss the miniature of the options isn't > > going to help. No solution is perfect - we just need to clearly > > document the implications of whatever we come up with. > > > > I lean towards 2a, but I be happy with with any '2' and '1' won't kill > > me. > > I guess I'd also lean towards 2a. > > I don't think it applies to posix acls, as overlayfs is capable of > copying those up and evaluating them on its own. POSIX acls are evaluated and copied up. I guess same goes for "security.*" attributes, that are evaluated on MAC checks. I think it would be safe to ignore failure to copy up anything else. That seems a bit saner than just blacklisting nfs4_acl... Something like the following untested patch. Thanks, Miklos --- fs/overlayfs/copy_up.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) --- a/fs/overlayfs/copy_up.c +++ b/fs/overlayfs/copy_up.c @@ -36,6 +36,13 @@ static int ovl_ccup_get(char *buf, const module_param_call(check_copy_up, ovl_ccup_set, ovl_ccup_get, NULL, 0644); MODULE_PARM_DESC(check_copy_up, "Obsolete; does nothing"); +static bool ovl_must_copy_xattr(const char *name) +{ + return !strcmp(name, XATTR_POSIX_ACL_ACCESS) || + !strcmp(name, XATTR_POSIX_ACL_DEFAULT) || + !strncmp(name, XATTR_SECURITY_PREFIX, XATTR_SECURITY_PREFIX_LEN); +} + int ovl_copy_xattr(struct dentry *old, struct dentry *new) { ssize_t list_size, size, value_size = 0; @@ -107,8 +114,13 @@ int ovl_copy_xattr(struct dentry *old, s continue; /* Discard */ } error = vfs_setxattr(new, name, value, size, 0); - if (error) - break; + if (error) { + if (ovl_must_copy_xattr(name)) + break; + + /* Ignore failure to copy unknown xattrs */ + error = 0; + } } kfree(value); out: