Re: [nfsv4] RFC: new optional attribute related to owner-override

David Noveck <davenoveck@gmail.com> Mon, 31 January 2022 13:59 UTC

Return-Path: <davenoveck@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 866483A3186 for <nfsv4@ietfa.amsl.com>; Mon, 31 Jan 2022 05:59:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HFbQc1kIqju for <nfsv4@ietfa.amsl.com>; Mon, 31 Jan 2022 05:59:47 -0800 (PST)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C4B3A317F for <nfsv4@ietf.org>; Mon, 31 Jan 2022 05:59:46 -0800 (PST)
Received: by mail-ed1-x534.google.com with SMTP id n10so26907439edv.2 for <nfsv4@ietf.org>; Mon, 31 Jan 2022 05:59:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IRKGQ843UuoGTFtOb3pEGH8YA6Y+n/JTofd6+hccNlA=; b=UkPXf7wKky8Wdj4b3h01VUvuVbZ+tloLJ6wvshmc5bdOU953xk6ceAHcvrbr4pcvmv bjr20QRZmOyC5rV0pkmxVYSFhBUdSDtV71zrafWS1i7o8HlIKUyEhxqaXdL4IWm26rXs BQOkTacKiQsQsx05yUGkxRj2iKUIOQLRyzs2/xfnAQuBzUQDWSglNU5KfUXRiTK/J/g+ mXUlo9i5zW11KoRM6W0n1afnrl/OASAHqOGmxEsynF2052YghOkQoJaw6OUQPZ7lXT/i xec3piO1WCTCyn6hg6HZhAKN8p88zKJPjAsfgas0P9qLoSnNsk4X7cimRzr0HFOQ7a+i MmhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IRKGQ843UuoGTFtOb3pEGH8YA6Y+n/JTofd6+hccNlA=; b=St1YvuptwIzEl4CtZ+Pedq/qIFvddi95NerkQUQFNweNt3Lb6cgNAa+62j0pkxlQu7 23YKTk8zQgg5I1kkUZTWmQNfmAIZqyD4ZKNwvxfFbeRfTQzfPyijLadph6PpBCZ2yVhh fqNEQozJGgQ+lJPgcAW2VDsBqEuT8ADM37N65yavQT9Jnk6BADjdLtdzMUEjl2dbbPvU OB/E8KVZL0MKkb0T4iUQnfd/PRlHYn4J5CzHWS7NVLJ7L0q+X7ib28n3xIg2ht9kBjGN H7MOwm+Z1uhLrJ/ZifGer84yfMdqcDo5ggwlXwQtMra5yHt1WG4FpM5zzLeboJPhkjrt ULgQ==
X-Gm-Message-State: AOAM5331TiWN6hvBEvWzegtBMNQiXcRmACU3ndruWIvYu4ufU0eJ8C/t l31fMTA8hphcGQ8MclB2tXEyF0ilj+W5KTJ2q1QNBBvSQ+s=
X-Google-Smtp-Source: ABdhPJy7TDI772xwpvZGbw9yMfFc/zoXFgY6whJvCMlgORhQZpem8loXfljkCkR6MelynEPJegfj44SVm8JkAtf4tik=
X-Received: by 2002:a05:6402:348a:: with SMTP id v10mr20920288edc.249.1643637583816; Mon, 31 Jan 2022 05:59:43 -0800 (PST)
MIME-Version: 1.0
References: <YQXPR0101MB096897EB25713A75300D937ADD239@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
In-Reply-To: <YQXPR0101MB096897EB25713A75300D937ADD239@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
From: David Noveck <davenoveck@gmail.com>
Date: Mon, 31 Jan 2022 08:59:32 -0500
Message-ID: <CADaq8jeZ_0neVTZrPM6uZqdLS_Rb-R+_CCUKmCh=uTxdV1gC6g@mail.gmail.com>
To: Rick Macklem <rmacklem@uoguelph.ca>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000052adcb05d6e132ae"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/qVRot_VPZXbLtdr_12Fc-ecuAN0>
Subject: Re: [nfsv4] RFC: new optional attribute related to owner-override
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Jan 2022 13:59:52 -0000

>I am thinking of adding this attribute to my draft, but thought
> I'd ask for comments first.

Thanks for asking.  I hope my comments below do not cause you to regret
that decision.

I believe that this is a helpful idea  to address a gap in existing
specifications and I would very much like to see it developed further.
However, there are a number of reasons that I think that putting it into
your existing I-D is might not be the right venue.

   - What you have proposed is really outside the scope of the NFSv4
   attribute model, at least when used with SETATTR, as you have proposed.  It
   doesn't really fit without other other attributes which do not seek to
   extend the attribute concept in a major way.   I anticipate that if you
   keep to the existing model, we could adopt that document as a WG document
   soon and look to getting to WGLC in about six months.
   - Even If you were prepared  to  cut this back  to a
   GETATTR/VERIFY/NVERIFY, it seems likely to me that the possible connection
   with draft-ietf-nfsv4-security is likely to add substantial delay to the
   process.   It's up to you but I would suggest getting done what can be
   (relatively) easily done now and defer the harder part until the future of
   draft-ietf-nfsv4-security is clearer.

Let me provide you some background about things I am expecting to do in
draft-ietf-nfsv4-security-05 and how I might address your work in that
document.

   - In a number of places in which existing specs create choices for the
   server (implicitly, not using "MAY" or "OPTIONAL"), I intend to refer, in a
   new subsection of Section 16 ("Future Security Needs"), to the *possibility
   *that new optional attributes could be defined to allow the client to
   understand which of choices left to it by the existing specs the server has
   chosen. Other than to list the issues to be addressed, it doesn't make
   sense for me to have much detail regarding documents not written or adopted
   as wg documents.
   - I could, if you are OK with it, include the read-only version of your
   attribute in that list.
   - With regard to the SETATTR use of your attribute, I think that the
   right alternative is to deal with this by adding new flags to EXCHANGE_ID.
    I think I could allude to this possibility in security-05, if you don't
   have a problem with that.

 As far as where to first publish your idea in a document, it seems to me
you have the following possible choices:

   - It could make sense as a separate I-D, either with the goal of wg
   adoption in this form, or expecting it to be merged into another
   document before working group adoption.
   - One possibility is to merge it with the similar attributes mentioned
   above to clear up ambiguities about various forms of essentially optional
   server behavior.   I could see work on this document proceeding in parallel
   with further work on security-xx and the rfc5661bis document suite.   If we
   took this approach, we would need to be careful not to create troublesome
   inter-document dependencies while keeping to a common approach to the
   matters under discusion.

I anticipate that security-xx would continue to deal with the options as
they are now without adding  references to the newsecattrs documents.

Once the newseecattrs documents is adopted, I expect it would refer,
informatively, to security-xx.   This migght delay newsecattrs publication
as RFC but i don't find that troublesome since necessary prototype would
probably not be impeded.


   - Another possibility, if you want to preserve the SETATTR-like part of
   this, is to combine it in a document addressing a set of desirable
   EXCHANGE_ID.   I have at least one such extension in mind, connected with
   smoothing the lock reclaim process in the event of large numbers of opens
   to be reclaimed.  I'll send a more detailed description in an email
   next week but will not have time to work on a document until security-05 is
   out.  Sigh!

I think that, for any of these approaches to the publication process, it
would help if we worked together on prototypes. I think I would be able to
do a prototype ontap implementation some time in 2022.  I think virtual
bakeathon testing is desirable but, if I can't get that arranged, I think
we could figure out other ways of doing interoperability testing.

On Sat, Jan 29, 2022 at 5:59 PM Rick Macklem <rmacklem@uoguelph.ca> wrote:

> I am thinking of adding this attribute to my draft, but thought
> I'd ask for comments first.
>
> This one would be per server (for a given client's ClientID) and
> would apply to the following operations:
> Read, Write, Setattr-of-size, Allocate, Deallocate, Copy,
> Open(Claim_delegate_cur/Claim_deleg_cur_fh)
>
> I am thinking of a tri-state attribute:
> 1 - A permission check is done via mode or ACL for each of the
>      above operations.
> 2 - The owner of the file is permitted to perform the above operations.
>      For non-owner requests, a permission check is done via mode or ACL
>      for each of the above operations.
> 3 - The operation is permitted, if an appropriate valid stateid(s) (not
>      special stateid(s)) is provided, plus:
>     - The client has been peer authenticated.
>     - At least integrity protection is being applied to the connection the
>       request is received on.
>     (Appropriate stateid would be defined, but for this discussion, I think
>      what is appropriate should be fairly obvious. Note that a lock_stateid
>      is always associated with an open_stateid via open_to_lock_stateid and
>      the open_stateid is for Read, Write, or Both access.)
>
> A server would not be required to support all 3 attribute values and
> would return NFS4ERR_INVAL for any value not supported when a
> Setattr of the attribute is attempted.
>
> The setting would apply to the ClientID implied by the Sequence
> operation for the compound the operation is in.
>
> The object would be to both document what the serve implements
> and to allow a client to select a preference, for servers that support
> more than one of the above 3 attribute values.
> (Probably an enumerated type when done in XDR.)
>
> So, what do others think? rick
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>