Is Read required on top of Write for PATCH delete and where ? #220
Description
Activity
I'm not sure which spec you're referring to but will take it as underspecified/unknown at the very least in the issues here and current Protocol spec. But right that the current web-access-control-spec alludes to
acl:Writeallowing PATCH.. and the wiki WebAccessControl doesn't requireacl:Read.
When using WAC, I agree on requiring
acl:Readandacl:Writein order to accept PATCH operations includingDELETE DATAorWHERE- at least those with application/sparql-update data type if anything.When agent doesn't have
acl:Readandacl:Writeon target, rejection should use the 403 status code.When agent has
acl:Readandacl:Writeon target and there is no match onDELETE DATA, rejection should use the 409 status code.I've documented some PATCH requests in a table based on
INSERT DATAandDELETE DATAin #14 (comment) as those appear to be the basic level of SPARQL Update we seem to agree on to date. Related issue: #125 . So,WHEREsupport needs an explicit agreement.See also for recent-ish description of the current state of things: CommunitySolidServer/CommunitySolidServer#15 (comment)
Reacted by Andreas KuckartzWith ESS, a PATCH operation does not require READ access.
There is also no locking mechanism and hence no notion of a semaphore in ESS (distributed locks are a nightmare); instead, it relies on a conflict resolution mechanism (e.g. last-write-wins)
Worth noting that one could apply a similar line of reasoning about conditional PUT requests (
If-Match, etc)So now that the test suite was updated 20 days ago to require Read access, CSS is failing that test. Marking that test as disputed now.
We probably can't answer this question without answering #139 first.
Reacted by Andreas KuckartzOK, catching up here...
Indeed, the
Readrequirement stems from the semaphore mechanism, because that leaks information.The deeper problem here is really how we design systems that allow for actual least privileges to be used. It is easy to say that it should follow the principle of least privilege, a different thing to design for it. To design for it, we need to make sure that all of SPARQL semantics maps well to access modes.
We could take the easy way out and have the semaphore mechanism and say that all SPARQL Update queries require Read+Write, but that wouldn't be a great design in light of the principle of least privilege. Then, we could also ensure ACID in the database but not allow these semaphores, but that puts the ACID requirement on all implementations, which is also a lot to ask. We could also spec a lot of special cases around it.
I gave this some thought a long time ago, and I think there is a reasonable middle ground, but it requires changes to SPARQL.
Conclusion: clients should just avoid ever trying to delete a triple that's not present, because as we've seen, different pod servers will react differently. Instead, a PATCH that deletes triples should always have an
If-Matchheader that avoids race conditions.This has been discussed a bit amongst the Solid Editors, and it has been decided that the semaphore mechanism is a requirement. It is considered that we should come up with a better design the future, but for now, that is the case. That decision makes it clear that the answer to the title of this issue is yes.
AFAIK, the mechanism currently applies to the
WHEREclause, but I think it is quite clear that the use case would naturally extend to a request withINSERT DATAandDELETE DATAas well. I also think timescale is a poor judge. In the post to SPARQL 1.2 CG, I use an example that involves these two operations, like this:Concretely, say that client 1 goes:
DELETE DATA { <foo> <baz> "Dahut" } ; INSERT DATA { <foo> <baz> "Bar" }
independently, client 2 goes
DELETE DATA { <foo> <baz> "Dahut" } ; INSERT DATA { <foo> <baz> "Foobar" }
before the first client as finished. The same semaphore would apply, as the server would respond with a
409to theDELETE DATAoperation of the second client.I realize that it would be a simpler implementation if the semaphore mechanism applied only to a
WHEREclause, but it seems rather odd to tie it to that, given the above.Thus, it seems to me that for now, we should require Read+Write privs for any SPARQL query with
DELETE.I hope that we can get to a SPARQL standard where any information exposure is tied to a projection, so that Read would only apply if you actually use the mechanism, but for now, I think the above is the best way to do it.
Can we arrive at a consensus that the semaphore mechanism applies to both
DELETEoperations, so that Read are required forPATCHcontaining those?+0.5.
Just want to highlight that the work in #14 (comment) is generally based on:
Resources can be observable or discoverable - "knowable" - by agents having Read access privilege either on the resource or its container (inherited).
While it is possible to distinguish between knowledge about the existence of a resource from the description of a resource, the general principle, i.e., requiring Read, seems to apply to both.
Edit: It may also apply to scenarios such as PUT with If-None-Match: * requiring both Write and Read.
This issue has been nominated for drafting phase for the next milestone.
Metadata
Metadata
Type
Projects
- Status
On PATCH spec seems to require only
Writefor sparql DELETE. This is implemented in solid/test-suite.But NSS is requiring
Read and Write, with the following explanations in the code comments in NSS PATCH implementation.What should be the spec ? What should test-suite implement if the response is not straight forward ?