[nfsv4] Linux NFSv4 client patch for testing the POSIX ACL extension
Rick Macklem <rick.macklem@gmail.com> Sun, 25 August 2024 23:08 UTC
Return-Path: <rick.macklem@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3B8C151069 for <nfsv4@ietfa.amsl.com>; Sun, 25 Aug 2024 16:08:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukXlZydtgPLM for <nfsv4@ietfa.amsl.com>; Sun, 25 Aug 2024 16:08:45 -0700 (PDT)
Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D66C9C14CE31 for <nfsv4@ietf.org>; Sun, 25 Aug 2024 16:08:45 -0700 (PDT)
Received: by mail-pj1-x1031.google.com with SMTP id 98e67ed59e1d1-2d439572aeaso2480407a91.1 for <nfsv4@ietf.org>; Sun, 25 Aug 2024 16:08:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724627325; x=1725232125; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=R+mWGZLoUR4z7/ooAwejwqFufaZaj6eddffUMVFOyss=; b=WT8Tv6kXbduZQTQLETeZDpctZv91K9yJEK7Kn/Ut8Pot4056J43LdbAEG8pfS6i5SL Idj3O0xrlzbXoesqrFKlNtvP1cgHzBKBVlGrPT5Np7nbtpydqqa1/QLFi/lizCnaHQoE YQaUrs5d5ot6RQ9QLZoy+Ww/pdq7seSKfE5ql1p4guJzMGJrenJ8pTw7B6bhnHM6NOIq Nr1vHD76BNpPIPvR/q0TtWKhvurrbRDrJgItAO3lcyfaViwQHxaWLgMzBRElEfdMjLVu EHLiRLxSNBsRtyDABdW3/DmIQFO/zMLvISu4hqzFXUSbBaWiqU2QsgI7b497cxYiToFf +7bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724627325; x=1725232125; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=R+mWGZLoUR4z7/ooAwejwqFufaZaj6eddffUMVFOyss=; b=GdjBRnc66eFJT0+tFx7kINS93CFGS2uuEmG5JjHiQOMkov4JFktjqVZRk/3aDhOeyr vxquRFx8OdQZOCefPIZQVNodFaWt8RJBfs3spnXOoapR5bRIKuQyHJadeFPIq/fxiP3l KcoYs8GO3XrJvsfLgYzhxpsiFcK0ZQKYrqmYIvD9bEqXkYELuHf1xwpJ9h81/RXUNCo3 RcXpw/YdfOuN9gIM01ZFu7FGEi0BDa0uMtb0vJlgKMmQbA7PCHN0ObvxsAMQPgAgmjdi VuJBtyWB56Hb12Gj4OVRKhZ97iFojPQy6EOhFL1OldIgkxXXPPR/4J4s2UlIL11T4eEk zYnw==
X-Gm-Message-State: AOJu0YyNIyeN7R4Q2PsTAvyVv7x2EgWuuKprHBOtbxtEKJ10HbW5zNEg qHtlwDduiasbr4rpUmkFb4fphc0F6SSC/i8UcvyX0jhKE7ukP/xZdnJyzWZ6eABo89TXKKpmc++ jBdIZtJvefx337KqpGjpswPckVaRCHE0=
X-Google-Smtp-Source: AGHT+IHbDZHB4QOuRwOzrY+sDAkhQdaetGRg+WpYEQapBcCdRjO8klCif1TBgSEu7KnGWuZaz4+iAC+TEBDuqPY3jU8=
X-Received: by 2002:a17:90b:3907:b0:2c9:a831:3b7d with SMTP id 98e67ed59e1d1-2d60a9fd3f2mr20529915a91.18.1724627324846; Sun, 25 Aug 2024 16:08:44 -0700 (PDT)
MIME-Version: 1.0
From: Rick Macklem <rick.macklem@gmail.com>
Date: Sun, 25 Aug 2024 16:08:35 -0700
Message-ID: <CAM5tNy43KSONVb=he_wScc4fzsnG8CGbwLqhmA1JQYjDiSO+ww@mail.gmail.com>
To: NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001149f706208a170a"
Message-ID-Hash: BAO7UOT64N34FWFEOILCST6333IN6XQF
X-Message-ID-Hash: BAO7UOT64N34FWFEOILCST6333IN6XQF
X-MailFrom: rick.macklem@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-nfsv4.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [nfsv4] Linux NFSv4 client patch for testing the POSIX ACL extension
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/LrvJWjLsqK-JS49fs7WckTmPYHU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Owner: <mailto:nfsv4-owner@ietf.org>
List-Post: <mailto:nfsv4@ietf.org>
List-Subscribe: <mailto:nfsv4-join@ietf.org>
List-Unsubscribe: <mailto:nfsv4-leave@ietf.org>
I keep trying to post this to linux-nfs@vger.kernel.org, but it keeps complaining about html in the message. So I am posting it here and hopefully some Linux folk will see it. (And maybe someone knows how to re-post it so that it works????) Here is a crude patch for the NFS client that can be used for testing the POSIX ACL extension to NFSv4.2 described in draft-rmacklem-nfsv4-posix-acls. https://datatracker.ietf.org/doc/draft-rmacklem-nfsv4-posix-acls/ It is done against a linux-6.3 kernel, but hopefully can be applied to newer sources fairly easily. For now, the patch is here: https://people.freebsd.org/~rmacklem/linux-posixacl.patch I am hoping this patch will encourage someone to do testing during the late Oct. NFSv4 Bakeathon. Since I am not familiar with the Linux NFS client code, there is a lot left to clean up before it would be useful for more than testing. Here's a few items: - The NFSACL protocol code pre-allocates pages for large ACLs. I do not do that. Unlike NFSACL (which puts uids/gids on the wire), the NFSv4 extension uses "who" strings, which can be up to 128 bytes (IDMAP_NAMESZ). As such, a maximum size POSIX ACL with 1024 ACEs can end up over 140Kbytes on the wire. I currently use xdr_stream_XXX() functions to fill out the encoded xdr, which seems to work? Thought needs to be put into how to handle large POSIX ACLs. - I haven't even tested large ACLs yet. - When I needed functions that were in nfs3acl.c or in nfs_common/nfsacl.c but "static", I just copied them into nfs4proc.c. (I think they could go in nfs_common/nfsacl.c as non-static and then be used by both nfs3 and nfs4 code, but I wasn't sure what the Linux tradition was?) - There's a bunch of dprintk()s in the code I used for debugging. Most of them should go away once the code solidifies. (Most start at the left margin of the line.) --> I don't know how the trace stuff works. That needs to be added. - The GETATTR for the POSIX draft ACLs also acquires the acl_trueform attribute. If that attribute is not set to ACL_MODEL_POSIX_DRAFT, a -EOPNOTSUPP is returned. I think that will make getfacl(1) return a POSIX draft ACL based on mode, but I am not sure? - I probably put stuff in the wrong places for a NFSv4.2 extension? - There doesn't appear to be any bits left for NFS_CAP_xxx, so I just used the NFS_CAP_ACLS one. (There probably should be a separate one, but this might work ok?) This one may only be a configuration problem, but even though I think I have the uid<->name mapping working, nfs_map_uid_to_name() always returns the "number in the string". --> To get setfacl to work, I have to configure my test server to use "numbers in strings". (nfs_map_name_to_uid() does seem to work?) Have fun with it, if you have the chance to look at it, rick
- [nfsv4] Linux NFSv4 client patch for testing the … Rick Macklem