`storage.create` includes protocol-specific behaviour
Closed this issue · 10 comments
Authorisation is the process of deciding whether or not a particular request is enacted; i.e., making a yes/no decision given a desired operation on a specified resource.
On page 12, the description of storage.create contains the phrase:
This capability includes the creation of directories and subdirectories at the
specified path, and the creation of any non-existent directories required to create the
path itself (note the server implementation MUST NOT automatically create directories
for a client)
It this phrase, is quite reasonable to include the statement:
this capability includes [...] the creation of any non-existent directories required to create the path itself
This statement is describing an authorisation decision: should the client attempt to create missing directories in the scope's path then such requests are authorised.
However, the parenthetical note regarding auto-creating directories (the server implementation MUST NOT...) is actually unrelated to authorisation. Instead, it's describing some aspect of the network protocol being used.
I suggest this parenthetical note is simply removed.
Hi Paul,
the text in v1.0 tried to convey implicitly that a client must NOT rely on the SE creating any missing leading directories automatically. Ergo: the client is responsible for checking if any such directory would first need to be created in order to allow the full path to be usable. That obligation is not obvious and shall therefore be spelled out in the document. I agree we can do better than what is written now. In particular, such an important message should not be conveyed parenthetically. For example, the sentence could state the following instead:
This capability includes the creation of directories and subdirectories at the specified path, and the creation, by the client, of any non-existent directories required to create the path itself.
What do you think?
In general, I agree with the sentiment in documenting this expectation somewhere. I'm just not convinced the JWT profile is the right place.
Note that the behaviour is independent of the AuthN/AuthZ scheme. What is written is also true when using X.509/VOMS proxy certs for authentication. It would still be true if (at some later time) WLCG moves to some other AuthN/AuthZ scheme.
It's also dependent on the protocol being used. WebDAV might not auto-create parent directories but some future protocol might. As a counter-example, consider S3, which (in effect) auto-creates parent directories.
As different protocols handle this differently, a safe ("lowest common denominator") approach would assume that parent directories are not created and the client should check for their presence and create them (as needed). This is what FTS does.
Hi Paul,
I think we should aim for our profile document to be self-sufficient w.r.t. any provisos of which implementers need to be aware for the handling of tokens described by the document. I therefore propose we adjust the text as suggested in my previous comment. What do you think?
Sorry, I re-read your sentence and it looks good to me.
Personally, I would drop the "by the client" clause: the token doesn't care which agent is requesting that the parent directories are created, just that it authorises that activity.
But please feel free to go ahead with the change.
I agree with the change, perhaps to clarify the parent directories situation:
This capability authorizes the creation of directories and sub-directories at the specified path, including the creation of any required non-existent parent directories needed to match the requested path.
It seems the change currently proposed in #42 is sufficient to deal with this issue after all.
Might we want to adjust this sentence as well:
This authorization DOES NOT permit overwriting or deletion of stored data.
Would it be preferable to say MUST instead of DOES?
Would it be preferable to say MUST instead of DOES?
I would suggest not changing the sentence to use MUST.
My take is that the RFC 2119 keywords are intended for nominative statements within a spec. The non-normative (i.e., informative) statements shouldn't include RFC 2119 statements.
Further, I take this statement as informative rather than normative. In general, the document describes what actions are authorised by some specific AuthZ statement. The document (in general) doesn't list what actions are not authorised by some AuthZ statement. The unauthorised actions (for some AuthZ statement) are assumed to be everything that isn't documented as being authorised.
In this case, the document is trying to be helpful (i.e., informative) and point out a possible mistake that the reader might make. Therefore, it would be better to avoid using RFC 2119 language here.
The other reason for avoiding this is that saying MUST NOT might introduce confusion. What is authorised if the token contains an AuthZ statement that MUST NOT authorise some action and another AuthZ statement that does authorise some action? For you and me, the answer is obvious but it might not be so obvious to someone else.
OK, should we consider changing DOES NOT to does NOT instead?
Yes. I'd be also happy with does not.
One could also include something like "by itself"; for example,
By itself, this authorization does not permit overwriting or deletion of stored data.
However, this might just be "bikeshedding" ;-)
I have changed it to: does not