Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp1798087rwd; Wed, 17 May 2023 01:15:31 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5fhGdGrGkrpCl745ZnT+WQgVxVcFvjoa/KQM61aZONYoKZl5yhF+BRbsoVxhi6Wcn2ePKD X-Received: by 2002:a05:6a20:244a:b0:107:1f22:10d5 with SMTP id t10-20020a056a20244a00b001071f2210d5mr5263661pzc.52.1684311331129; Wed, 17 May 2023 01:15:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684311331; cv=none; d=google.com; s=arc-20160816; b=W4VMJBbd60/mOqBoMSpj8mD7+B26OeBD3AZQDZnT9hMgnEu9w5pV/P9VXzq4AtXm8o ME7a8RYIfXVDTh7FMPeuw4Z3dmPuTZ46C0Cfj7REhR7uijgromhzCtPwc1M1GR6hHl+a 8vNWPnVFYwupvbtJsQDvonigohxaniU1S6yOEPx4yhtbsKfB2HgseGEdccEAbIjnhxyE zL5JjertKh9WbkSRiE+qRD5OCDv6gNr43ejMe0VaUT8NQrQErtoe3LxI9jy8suIFd3H6 Ws69VFDvCYo1z8silB7B1ec9jA1Pw2VyVzthnrTLr38glLbuZugGWc6IbbcSylQr9asi wzyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=P3m2LUajrOIdFks25vhenAARfxeFQmdL4GyJAfJL6B4=; b=J3NuXxfSRpWwhB+tFVqIbc2ckVKYGXQGA9BYSvdOtTik6C+dLUPGslmOuI/ttRg6pN yEH82rhH4a9mwZ3MtqxKPH/m7C4i8uvcYwI/Ys1S1Jjhu8qRnXYc/uKnyEpcBFVy4Xfi tBNsxaakMaRjER++Mt/AKAxQdj7Jer9cYMt9DANOOPaCMEIGVfdtEChMhTcvQNcsqLhI YNuIpJXnMZUnh+p+3ZSecjDVTadEtPRpbUDUACN7W6YZxItZNZE5apJHy4xof631BBo6 51+t8EoTqQIST3xPFkt5ah04SstsTVOrRtPt6V9ieDlZan/4goaJlj9TKPGyNIZ+1FUK QTEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SLx3zhrn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y187-20020a638ac4000000b005142038a8c7si20686295pgd.291.2023.05.17.01.15.16; Wed, 17 May 2023 01:15:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SLx3zhrn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230136AbjEQHnH (ORCPT + 99 others); Wed, 17 May 2023 03:43:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40242 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230025AbjEQHnG (ORCPT ); Wed, 17 May 2023 03:43:06 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5423BDA; Wed, 17 May 2023 00:43:05 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E04A261505; Wed, 17 May 2023 07:43:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7059C433EF; Wed, 17 May 2023 07:43:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684309384; bh=O9BH3MMwJ9QLfDiBDxx6MYQ6q0OrfOn8kxK3I1Ze9Yo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SLx3zhrnBRX6BxumCB+uz3OasNrIpbQdUVmqHECCNSMmOYtLfHVLI/2UdI8m4bXmO Iy6AzzQIxzE+3p194U1XkRaTZvpVKg+zmEfpwmZQkSwWKrXu689ly7ad5ROanbBmJT 1LPT43AY7EcRHmZj35LxqtRBKrdO5SHnSplTwn2gzEd9SY8iIEgkn627b/nfqmz3MS 2gQ5joEbjYPfCXNc0j1oItjy9zHwQdceeUxO9aGXq4GoTQJWusb40Xj4xBhSpEl8vn ELQ1Sm6wLqvecjdmaZXocjz1upV+qrC2V463RyiWMRV2sfvGsWiV3mLf/xp6BGrfCJ eQ2C/llrMFFog== Date: Wed, 17 May 2023 09:42:59 +0200 From: Christian Brauner To: Jeff Layton Cc: Ondrej Valousek , "trondmy@hammerspace.com" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: A pass-through support for NFSv4 style ACL Message-ID: <20230517-herstellen-zitat-21eeccd36558@brauner> References: <20230516124655.82283-1-jlayton@kernel.org> <20230516-notorisch-geblickt-6b591fbd77c1@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 16, 2023 at 05:22:30PM -0400, Jeff Layton wrote: > On Tue, 2023-05-16 at 20:50 +0000, Ondrej Valousek wrote: > > > > Hi Christian, > > > > Would it be possible to patch kernel the way it accepts native (i.e no > > conversion to Posix ACL) NFSv4 style ACLs for filesystems that can > > support them? > > I.E. OpenZFS, NTFS, could be also interesting for Microsofts WSL2  or > > Samba right? > > > > I mean, I am not trying to push richacl again knowing they have been > > rejected, but just NFS4 style Acls as they are so similar to Windows > > ACLs. > > > > Erm, except you kind of are if you want to do this. I don't see how this > idea works unless you resurrect RichACLs or something like them. I have no idea about the original flame war that ended RichACLs in additition to having no clear clue what RichACLs are supposed to achieve. My current knowledge extends to "Christoph didn't like them". > > > The idea here would be that we could > > - mount NTFS/ZFS filesystem and inspect ACLs using existing tools > > (nfs4_getacl) > > - share with NFSv4 in a pass through mode > > - in Windows WSL2 we could inspect local filesystem ACLs using the > > same tools > > > > Does it make any sense or it would require lot of changes to VFS > > subsystem or its a nonsense altogether? Yes, very likely. We'd either have to change the current inode operations for getting and setting acls to take a new struct acl that can contain either posix acls or rich acls or add new ones just for these new fangled ones. Choosing the first - more sensible - of these two options will mean updating each filesystem's acl inode operations. Might turn out to not be invasive code as it might boil down to struct posix_acl *acl = acl->posix at the beginning of each method but still. Then we'd probably also need to: * handle permission checking (see Jeff's comment below) * change/update the ACL caching layer * if the past hast taught me anything then overlayfs would probably need some additional logic as well > > > > Eventually you have to actually enforce the ACL. Do NTFS/ZFS already > have code to do this? If not then someone would need to write it. > > Also windows and nfs acls do have some differences, so you'll need a > translation layer too. Jeff, I know you have some knowledge in this area you probably are better equipped to judge the sanity and feasibility of this.