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

[David Noveck <[e-mail]>]

On Mon, Jan 31, 2022, 8:13 PM Rick Macklem <[e-mail]> wrote:

> Hopefully people don't mind a top post...
>

I certainly don't mind.


> Thanks David, for your comments.
> I am comfortable with anything that you think fits well with
> your security work.
>
> I agree that an attribute that is per clientid is pushing it, and
> I think you are correct that it is not acceptable.
>

In security-05, I will mention the need but not get into details regarding
solutions.

>
> A read-only attribute might be useful, although I think allowing
> a client to negotiate a preferable security model would be beneficial.
>

I agree but to me this is a question of time.  A better solution is to be
preferred but I'm prepared for something good enough

>
> I am not sure that extending ExchangeID is a good plan, since it works
> well in its current form and doesn't need additional complexity.
> Another possibility is a new operation that a client can use to
> negotiate security options. The attribute proposed one set, based
> on the "owner override" concept. There may be others that become
> clear during your security work?
>

I haven't come across anything that would not fit the attribute model in
which the server chooses and discloses it's behavior.

>
> I would like to wait and see what others think.
>
> I will not be adding this to my current draft, since I no longer believe
> that an optional attribute is the correct way to do this,
>
> rick
>
>
> ________________________________________
> From: David Noveck <[e-mail]>
> Sent: Monday, January 31, 2022 8:59 AM
> To: Rick Macklem
> Cc: [e-mail]
> Subject: Re: [nfsv4] RFC: new optional attribute related to owner-override
>
> CAUTION: This email originated from outside of the University of Guelph.
> Do not click links or open attachments unless you recognize the sender and
> know the content is safe. If in doubt, forward suspicious emails to
> [e-mail]
>
>
> >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 <[e-mail]<mailto:
> [e-mail]>> 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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/nfsv4
>