[nfsv4] Re: Our different approaches to draft POSIX ACL support in NFSv4

Rick Macklem <rick.macklem@gmail.com> Fri, 26 July 2024 11:05 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 8335CC1840ED for <nfsv4@ietfa.amsl.com>; Fri, 26 Jul 2024 04:05:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 t_hJzNhgYPC6 for <nfsv4@ietfa.amsl.com>; Fri, 26 Jul 2024 04:05:40 -0700 (PDT)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11AC7C180B6A for <nfsv4@ietf.org>; Fri, 26 Jul 2024 04:05:40 -0700 (PDT)
Received: by mail-pg1-x52e.google.com with SMTP id 41be03b00d2f7-7ab34117cc2so565989a12.0 for <nfsv4@ietf.org>; Fri, 26 Jul 2024 04:05:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721991939; x=1722596739; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=eANrFLP8swbnIshz5HzBGeZR4C3F3vH35tOGXDwnI90=; b=MPI4zNuHaaGIKM5cwSFggCJ+2ZCPCDCkEoWtex0QZO3bfTAsw8d9rJkJhYBir0hJdr j6V+kbYArErQ2Z3mkOoTVQBNmdHhj7uLAlma5h06yhJ5620mym5aOP/d4v6OpDNoK6hF ZohYSh+CsO95uU7Bc3A2rQaI6in2wHfSl0hQ+cCJPzYdwaaEwBzNfeClMLjqxmahLv29 hq7O7j6hS4UHp4S0Hy2TEcaN0b0PstfkTVYP87rLbL0+/fDCc5DEOEntyYSsdE0DGVcQ 3jtrYVVVzoYy01uRflrgtVbPm1kNNfDPUmkfl5W3Wf24zJRtBGui1txZOhbBNwWi3N7T E1yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721991939; x=1722596739; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eANrFLP8swbnIshz5HzBGeZR4C3F3vH35tOGXDwnI90=; b=iePvPcGcjpOGzXBGrjjMX/1DcuL3FCC7UGuDgE67m7iKbRTd9KAMorxRHIbOfIk5QM 4hrc9mJsdZ5vgfbpIr1cHFJ/Q1O0Bmb+cKxR1A7a+7e5ATXcM45fmTyxTkINl+JLorM4 TF/5s7A0H7eUF4gn8b3lUcMgB93ZiBmSW4sjHXK1+OIzvi1JcKigNSxeobX/r2j4M5AX DX1NlxLKApu3tQj0aostj5fEBhsMAC6m4DGKZkvTwu/aACzF76bKhxMUd4fem8MEOeuy jlCCvz+ADnLwS19slMMLUnwyWwerj3Qe38xrJ6Q97zn2hmP3tic2RfGkIhfwlh+BJmSf 636Q==
X-Forwarded-Encrypted: i=1; AJvYcCVk9TOjzmLW56Y87aK41IB307NAGz1pMGQYTbSrWDZl9nNP65i39p5mRTlocojKjTsee0NSoT9BuBTm7+EBhA==
X-Gm-Message-State: AOJu0Ywkafft8gt39jEUQw7pU/UTKj+rTkOcyIYuqcTC4lTle9eDivH/ AzGg6ApCAwHQ3odA6L0zti2smkbdNaVlhTi/LE4FK/6L2rSSZPAQmZBesnbMMgQg25+GV8RJ6JL 1D5HLCzmJQWrtAU098f6VZrmRzw==
X-Google-Smtp-Source: AGHT+IHtUlNzkKVvhHIh0f4Sqc2Evwq4sQuRIh42Ic5WDT4hvqOwYHzmAcUSDYZHc5D/tBh8ybodhNHq4PREi3OubCM=
X-Received: by 2002:a17:90a:67cd:b0:2c9:61f9:a141 with SMTP id 98e67ed59e1d1-2cf237a0f99mr6371135a91.16.1721991939287; Fri, 26 Jul 2024 04:05:39 -0700 (PDT)
MIME-Version: 1.0
References: <CADaq8jdvZ5pcFNN5zjuVHLTO30v9=2kYKzFdRxxbkTmHYZdTdA@mail.gmail.com> <CAM5tNy7Fw954gCzYHCTjRg7th_njSHhxznni48Zz4xsSXT631A@mail.gmail.com> <53DAEF45-2A4D-4066-97C2-7B09018DE99B@oracle.com> <CAM5tNy6a4ZG90i2ugXzuPqQ1zrsK9m8jLRKmv9VpnFG6m_Pqew@mail.gmail.com> <DD250FBD-A434-4294-818A-5728757CE032@oracle.com> <d1c538065728c17df66a6f9e79e55d90849fc866.camel@gmail.com> <D352FEB9-A487-4B3E-9BC8-DB2C1896F941@oracle.com> <8efc39289ecef97624622cfc431f890736b579a0.camel@hammerspace.com> <33FA1D6E-73B3-43A1-B65C-D806156E39A5@oracle.com> <cf8a48e517210512755455dd78352ae5b64f7949.camel@hammerspace.com> <449AF448-1471-47CD-B5C5-3A3A5FB9FB12@oracle.com> <2e32694382df3e70a93edcf40434a41729031e55.camel@hammerspace.com> <83c39a7b12c05b0f1a0fa6e069b08e399864277a.camel@hammerspace.com> <CADaq8jfw1FVH3dxOEJAZLrw_S5y2F6eaGkcfpha4X8BBNWgRSQ@mail.gmail.com> <6903782a95875541489844e33541114f0bf01acb.camel@hammerspace.com> <CADaq8jdFYo_DtRxS3h17dyQSFqXeoR60OjsjMM=o35HDg8ZnNg@mail.gmail.com> <855662e75c4433042fd9875c2c9c5d0244c929da.camel@hammerspace.com> <CADaq8jdZzqt-bXB4YsO=R2qpT9MNfwvSAJyBJng1qjGFTn2tbw@mail.gmail.com> <CAM5tNy5oVnyP66fzZsQXnNQcTYtpQaR59Q6io92F4LX74gPivQ@mail.gmail.com> <7FAE51A2-6E14-412F-8B0A-AC617AE4173B@oracle.com> <CADaq8je9VqYoe8StfezCNjYPD3-dGmbz-zNSO51RBmfzCPcgeA@mail.gmail.com>
In-Reply-To: <CADaq8je9VqYoe8StfezCNjYPD3-dGmbz-zNSO51RBmfzCPcgeA@mail.gmail.com>
From: Rick Macklem <rick.macklem@gmail.com>
Date: Fri, 26 Jul 2024 04:05:23 -0700
Message-ID: <CAM5tNy5Md1c=GLzuW8vrzJ1j0U+-x5VLD-kLUBvETv6x9uu_vw@mail.gmail.com>
To: David Noveck <davenoveck@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d8f1ff061e247d3a"
Message-ID-Hash: 7AF4CEPWG6L4WL4SGFS3JYA2AYYYOS66
X-Message-ID-Hash: 7AF4CEPWG6L4WL4SGFS3JYA2AYYYOS66
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
CC: Trond Myklebust <trondmy@hammerspace.com>, Bruce Fields <bfields@fieldses.org>, "nfsv4@ietf.org" <nfsv4@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [nfsv4] Re: Our different approaches to draft POSIX ACL support in NFSv4
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/iqeNLjPygiPiZpLVHGCvTBpNjsM>
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>

On Thu, Jul 25, 2024 at 12:36 PM David Noveck <davenoveck@gmail.com> wrote:

>
>
> On Thursday, July 25, 2024, Chuck Lever III <chuck.lever@oracle.com>
> wrote:
>
>>
>>
>> > On Jul 25, 2024, at 9:44 AM, Rick Macklem <rick.macklem@gmail.com>
>> wrote:
>> >
>> > Christoph pointed out to me that having multiple ACLs on a file is not
>> > reasonable.  The draft I am writing will require a server to only
>> support
>> > one ACL model/file. (I think it needs to be a server choice and could be
>> > indicated to the client by which attributes are supported for the fiile.
>> > (This is related to the last point.  I'll leave the rest for others.)
>>
>> I agree there should be one per file,
>
>
> Definitely.
>
>>
>> and that the server's
>> local file system should determine which type of ACL it can
>> support.
>
>
> I would think it determines the set of types  it  an support.  This can be
> ofen will be a singleton or the null set.
>
> (I don't envision a scenario where one file system
>> could support multiple types of ACLs).
>
>
> I consider it unfortunate that your vision is so limited.
>
> I expect to face the issue in the near future since Netapp supports a
> considerable portion of the NFSv4 ACL model and will want to support the
> draft POSIX ACL.
>
> I don't think it is reasonable to tell users that they have to get rid of
> their existing ACLs in order to allow them to use draft POSIX ACLs.
>
If you are referring to the granularity of whether a
NFSv4 ACL or POSIX draft ACL is applied, I do not see
a problem with "per file" granularity, which is what I
had planned for the draft I am writing (in progress).
(My limited vision comes from the fact that FreeBSD uses
a "per file system" mount option to define which ACL model
is used.)

However, if you are suggestion that a file object could
have both a NFSv4 ACL and a POSIX draft ACL, then I do
envision problems.
--> How would the server check access?
    - By checking both ACLs and only allow access if both
      ACLs allowed access?
      --> That would cause confusion for users on clients
          that only see one of the ACLs, when the ACL the
          client sees allows access, but the server replies
          NFS4ERR_ACCES, since the other ACL does not allow
          access.

rick



>
>
>>
>> > It would be nice if, somehow, the Linux folk could determine how often
>> > the mapped NFSv4 ACLs are used on the Linux NFSv4 servers?
>>
>> As far as I am aware, NFSD does not use mapped ACLs, but I
>> haven't done an in-depth look.
>>
>>
>> --
>> Chuck Lever
>>
>>
>>