Is Read required on top of Write for PATCH delete and where ?

[bourgeoa]

On PATCH spec seems to require only Write for 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.

// Read access is required for DELETE and WHERE.
// If we would allows users without read access,
// they could use DELETE or WHERE to trigger 200 or 409,
// and thereby guess the existence of certain triples.
// DELETE additionally requires write access.

What should be the spec ? What should test-suite implement if the response is not straight forward ?

[csarven]

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:Write allowing PATCH.. and the wiki WebAccessControl doesn't require acl:Read.

---

When using WAC, I agree on requiring acl:Read and acl:Write in order to accept PATCH operations including DELETE DATA or WHERE - at least those with application/sparql-update data type if anything.

When agent doesn't have acl:Read and acl:Write on target, rejection should use the 403 status code.

When agent has acl:Read and acl:Write on target and there is no match on DELETE DATA, rejection should use the 409 status code.

I've documented some PATCH requests in a table based on INSERT DATA and DELETE DATA in #14 (comment) as those appear to be the basic level of SPARQL Update we seem to agree on to date. Related issue: #125 . So, WHERE support needs an explicit agreement.

See also for recent-ish description of the current state of things: CommunitySolidServer/CommunitySolidServer#15 (comment)

[acoburn]

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

[acoburn]

Worth noting that one could apply a similar line of reasoning about conditional PUT requests (If-Match, etc)

[michielbdejong]

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.

[kjetilk]

OK, catching up here...

Indeed, the Read requirement 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.

[michielbdejong]

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-Match header that avoids race conditions.