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

[Rick Macklem <[e-mail]>]

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

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.

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

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 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