Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp2380537rwd; Fri, 19 May 2023 05:09:17 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4hXeDvaMuldkeVZ+cboJUM57baHip+nRDqYx3lIGslKrukVhLBAinmOgGVqIaxBlLdLUcP X-Received: by 2002:a17:90b:1b49:b0:24d:ec9e:43d8 with SMTP id nv9-20020a17090b1b4900b0024dec9e43d8mr1986029pjb.7.1684498157642; Fri, 19 May 2023 05:09:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684498157; cv=none; d=google.com; s=arc-20160816; b=wwm0qWlGMaJ+cSGhUVZQOfZfo9KCsu2znm4B7ERSbDdzORf8Vt6s5zrHXrV8M19kE3 b6FF7TB/fCIZ46CKidJBStsW4E28Vw6sEjCnmwryGudYNARUTAlkU+8d32XbKxiY+1pR 0SSl9KU2E8FoHb/VblSI4cedWg+m+uwhnwIol1M6+m/4Cho11OSvXNLluvEcwLPiUVXM l7m3m8C7MFqIw/TEpmhrnH5/NSny1EeP2VXHQOnCo1OdRPnJUtYWrQ8mjgAKsvQUhi/0 i8yuKN68FAQ3ZRZA4h1EzSreZqsg/4NYdRiZ9X0urrfc5fD9VymiQmo+Rkccf+s8id5H UU8g== 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=G8JPtlc3IJbq3f+AqnMaUzQMCWixvKmDrKJ6d60JEk8=; b=JLka+QBLBYFi4QIRredwzYmTzm6394EQ0yJRPp3Jto6bbqjZMYXOQIHw35V65lmUt8 mVbHfBTDW7JleB2a+Xf4jAqA601NA8jqOKrscYqd66d9eUMuIItwv1nD/1zJvZIZiWTZ 7zQ2GIccW1G4IlUBxgW9g27qLkDZJZMOX8gYEOIpjvQVD8eIEdFO2DgIiVBHyhiCrGK+ 5M+z9rL7DYfoqi8DWcW0xKmFUIdjFtWZZpMVlx5f6ZHIFnwgKE6ZcudKLyWLUbGl7YWI SM3J3IH889H/u4i3Pz9zSFqbu3OQtPxfG0T2uOvzioCLFRpPuSS9qAVCrETe3bz/0l+7 puQg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=nsLYf9h3; 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 e24-20020a17090ab39800b0024730b93a6asi1614422pjr.147.2023.05.19.05.09.01; Fri, 19 May 2023 05:09:17 -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=nsLYf9h3; 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 S230525AbjESMCc (ORCPT + 99 others); Fri, 19 May 2023 08:02:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44744 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230240AbjESMCb (ORCPT ); Fri, 19 May 2023 08:02:31 -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 EFF6C18F; Fri, 19 May 2023 05:02:28 -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 852B565714; Fri, 19 May 2023 12:02:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 441D7C433EF; Fri, 19 May 2023 12:02:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684497748; bh=aUS8W90dTjFtHRr5ELiJEI3YIx95XhkEyqi9qJUIPf0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nsLYf9h3VKVvflYL7lhrEMVuy931qaFIru5NBh429e/ULynt2sWUkpSwykjNaN0zD BJPSmzqsYRs6eLCb35SSGOHx1gVzVkPdmvtaIqlB/S/0LLAo/6eAYIMMKfljMlGUHr dOBZ3ahBiDeL0P8YYnrY2K8gpGAGl/so9UZsbHzbywsaLwSboq4mMEFwAQzVxizGsn 6dgDKIEnNpRaw5951EzV/3U9N3MetZdwCPNUhUGuDiZ8bZDVIVFbwxwzRP2SGDrO+g q6mkYPqYYUIBctcbwcMIHDJJUHs2oGy78pT8AuUx8MjZYBABAIv92mDOHHh2wJb8sw IsQE4FbELGTEw== Date: Fri, 19 May 2023 14:02:23 +0200 From: Christian Brauner To: Ondrej Valousek Cc: Theodore Ts'o , Jeff Layton , "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: <20230519-verfrachten-gurte-a648ebd0a2fa@brauner> References: <20230516124655.82283-1-jlayton@kernel.org> <20230516-notorisch-geblickt-6b591fbd77c1@brauner> <20230517-herstellen-zitat-21eeccd36558@brauner> <20230517123914.GA4578@mit.edu> <20230519-allzu-aufmerksam-c3098b5ecf0d@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 Fri, May 19, 2023 at 11:38:30AM +0000, Ondrej Valousek wrote: > > > > I'll note most of this complexity is only necessary if you want to > > have local file access to the file system work with similar semantics > > as what would get exported via NFSv4. If you didn't, you could just > > store the Windows-style ACL in an xattr and just let it be set via the > > remote file system, and return it when the remote file system queries > > it. The problem comes when you want to have "RichACLs" actually > > influence the local Linux permissions check. > > > Yeah, I'm already scared enough. > > Well I do not think it's that difficult. As I said, just take a look how OmniOS does things, very nice - you can set up a VM with it in just a half an hour and you get a system with ZFS and native NFSv4 working. > True it's not Richacl, but just NFSv4 style acl - even better. > > As for the implementation, lot of code could be presumably taken from Samba which is already doing Windows style-ACL to NFSv4 translation. > > To me interesting bit was that the original path from Andreas was not accepted largely because it would add another piece of mess to the already messy code in the kernel, I did not know that. > I hoped that now that Christian cleaned the code recently, it would perhaps allow us to reconsider things, but maybe I am too naive here ???? Noo one is going to stop you from writing the code and posting it on the list. But I think none of us here will be very eager to implement it. If it can be done cleanly without performance regressions or unwiedly complications in the generic lookup and permission checking code and both posix acls and these nfs4 style acls can be abstracted away nicely in a single file, and have well-defined semantics and there's a clear use-case that isn't just someone's hobby project then it might be considered. But it might also mean you've spent significant effort just to hear a no in the end.