Re: [nfsv4] (belated) copy of my review of draft-ietf-nfsv4-layout-types-03 (part 4)

[Thomas Haynes <[e-mail]>]

Here is part 4:

On Jul 16, 2015, at 4:21 PM, David Noveck <[e-mail]<mailto:[e-mail]>> wrote:



Object Layout Type


Within the first paragraph:

  *   I don't understand the first sentence as written.  Is the following  reasonable replacement?

The Object Layout Type provides that security checks occur during the allocation of a layout.




With the object layout type, security checks occur during
      the allocation of the layout.


  *   The second sentence as written seems to (typically) require one LAYOUTGET per IO.  I'm sure that isn't intended.  Would the following make sense?

The client will typically will typically ask for layouts covering all of the file and may do so for either READ and READ/WRITE.  This enables the client to do subsequent IO operations without the need to obtain layouts for specific byte ranges.




  *   With regard to the third sentence there are some difficulties that from inappropriately combining issues elated to authorization and those relating to locking:
     *   It doesn't make sense to speak of verifying permissions against outstanding locks since locks are owned by owners and not users/principals.

I’ll strip out the lock observation since RFC 5664 spares one sentence for locking.



     *   It seems incongruous to speak of verifying permissions against layout iomodes. Actually, layout iomodes are verified against permission (i.e. mode and acls).

  *   As regards the last sentence of the paragraph:
     *   Whatever you want to say about authentication her, clearly authentication has nothing to do with issuing ACCESS or OPEN calls.

Section 13 of RFC 5664:


   When the client acts on I/O
   operations on behalf of its local users, it MUST authenticate and
   authorize the user by issuing respective OPEN and ACCESS calls to the
   metadata server, similar to having NFSv4 data delegations.

and later in that same section:


   A pNFS client will typically hold one layout for each byte range for
   either READ or READ/WRITE.  The client's credentials are checked by
   the metadata server at LAYOUTGET time and it is the client's
   responsibility to enforce access control among multiple users
   accessing the same file.  It is neither required nor expected that
   the pNFS client will obtain a separate layout for each user accessing

   a shared object.  The client SHOULD use OPEN and ACCESS calls to
   check user permissions when performing I/O so that the server's
   access control policies are correctly enforced.  The result of the
   ACCESS operation may be cached while the client holds a valid layout
   as the server is expected to recall layouts when the file's access
   permissions or ACL change.




     *   I don't see why you would issue ACCESS (as opposed to OPEN) calls. Is this to enable IO with anonymous stateids?

You would have to ask one of the authors of RFC 5664.



     *   I don't see how this similar to having a data delegation. One always has to do an OPEN whether you have a data delegation or not.

Again, ask the authors...


In the first sentence of the second paragraph. the phrase "inside the layout" seems misplaced.  How about the following proposed replacement?


Upon successful authorization, the client receives, within the layout,  a set of object capabilities allowing it I/O access to the specified objects, with the requested iomode.


Took an edited version


As regards the long final sentence of the second paragraph, the fact that it includes the word "MUST" means we need to exercise particular care:

  *   Suggest replacing "enforce access control" by "enforce access control and loocking semantics”

Ack

  *   Suggest replacing "Whenever the metadata server detects one of:" by "Whenever any of the follow occur:

We still need to call out it is the responsibility of the MDS and not one of the other systems.

Whenever one of the following occur on the
      metadata server:

  *   With regard to "the permissions on the object change", it should not be necessary to change the capability unless the change make access permissions more restrictive.

Making such a change would be a normative change to RFC 5664.



  *   With regard to "a conflicting mandatory byte-range lock is granted", since layouts are not owner-specific, it isn't clear exactly what is meant here by "conflicting”.

A good question to ask the authors of RFC 5664.


It appears that what is meant here is that you need to change the capability when there is a conflicting mandatory byte range lock obtained by another client.

It appear to me that the model for locking is that MDS is responsible enforcing locking between clients while the client is responsible for enforcing locking among owners within a single client.  I hope that's right.  It's all I can think of.

  *   With regard to, "a layout is revoked and reassigned to another client", the capability change should follow the revocation and should occur independently of any potential layout reassignment.
  *   Should also look at adding some the following:
     *   Revocation of a delegation, open or mandatory byte-range lock held by the client

Another normative change.

My hands are tied with respect to both the block and object layout types - I do not have any
implementation experience with them and have to go by what the authors specified as gospel.

  *   At the end of the sentence that the bullets are part of, suggest replacing "it" by "the metadata server" and "to implicitly invalidate'" by "in order to invalidate”

Ack



Summary

in the second sentence, suggest replacing "decisions seem to be forced" by "choices are conditioned".

I have a number of problems with the third sentence:

  *   Given, that, as indicated above, these choices are essentially dictated by the choice of storage protocol, I don't see how implementing any particular control protocol could be expected to change that.

A perfect example is with loosely and tightly coupled flex file implementations.



  *   It's not clear what the phrase "a real control protocol" means given the definition of a control protocol as "a set of requirements". I'm supposing this means "a 'control protocol', as that phrase might normally be understood", but this needs to be clarified. It is possible that the definitions I proposed for section 2 might help here. Then again,maybe not.

Took out “real”.



With regard to the first sentence of the second paragraph, I think "as we have seen" is not appropriate.  I don't see where this has been shown (or demonstrated) to be the case.  In fact, the control protocol has been defined to be a set of requirements and this sentence appear to draw conclusion from this fact, which is not appropriate.  How about the following as a replacement?

In the context of this document , we treat the control protocol as  a set of requirements.

With regard to the second sentence of the second paragraph, I have the following proposals:

  *   Replace "enclosing: by "defining".
  *   I have problems with the word "minimally' as it suggests something that only meets these minimal requirements is essentially OK.  I can see how you might want to stress (1) and (2) as especially important.  So how about the following:
     *   Drop the word 'minimally".
     *   Add the following paragraph at the end:

In addition, the document needs to make clear how other semantic requirements of NFSv4.1 (e.g. locking) are met in the context of the proposed layout type.


Ack


Security Considerations

I think you need a few introductory paragraphs, such as the following:

This section does not deal directly with security considerations for existing or new layout types. instead, it provides a general framework for understating security-related issues within the pNFS framework. Specific security considerations will be addressed in the Security Considerations sections of documents specifying layout types.


I really like that first paragraph...


The layout type specification must ensure that only data accesses consistent with the NFSV4.1 security model are allowed. It may do this directly, by providing that appropriate checks be performed at the time the access is performed, or by allowing the client or the data storage device to be responsible for making the appropriate checks, with the support of the metadata server. In the latter case,, IO access writes are reflected in layouts and the layout type must provide a way to prevent inappropriate access due to permissions changes between the time a layout is granted and the time the access is performed.


Took an edited version.


I think the following paragraph could appear after yours:

After such termination of access, the client has the opportunity to re-acquire the layout and perform the secuirty check in the context of the newly current access permissions.

Note that I am saying here that revocation of layouts is not required to enforce access permission chnges in the case of the file layout.  It is required to enforce locking., but not access permissions.  is this a problem?

No, because it may be required in another layout type



_______________________________________________
nfsv4 mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/nfsv4