solid / specification

Solid Technical Reports
https://solidproject.org/TR/
MIT License
483 stars 45 forks source link

Unsufficient restriction over user supplied containment triples #451

Open damooo opened 2 years ago

damooo commented 2 years ago

Currently following requirement is the only one that restricts user supplied containment triples.

Servers MUST NOT allow HTTP PUT or PATCH on a container to update its containment triples; if the server receives such a request, it MUST respond with a 409 status code. [Source]

But that allows including containment triples in representation of to be created container, when container is created through POST on parent container.

It may not be the intention.

csarven commented 2 years ago

[1] Whether and how the server should process that particular payload is unspecified. Hence, servers are neither required to accept the request; to further create new resources based on the containment statements in the payload; to include those containment statements in the description of the newly created resource (but without creating the contained resources as described in the payload), or; anything else for that matter.

Furthermore:

if the intention of the request is to create a non-container resource, then the containment statements in the payload are invalid use of ldp:contains (since it is only containers that can contain resources, as opposed to non-containers) - there is no meaning or behaviour for a statement like </foo> ldp:contains </bar> (where /foo is a non-container) in the description of /foo. It can indeed exist in that representation (as per Open World Assumption...) but again, unintended use and meaningless for clients.

If the request is to create a container as a member of another container (i.e., the target of the POST request) and includes a payload with containment statements, then [1].

(I couldn't resist the circular explanation :))

damooo commented 2 years ago

As most implementations doesn't prefer(?) to allowing arbitrary containment triples and creating resources, and clients expect all ldp::contains statements in a container rep are server managed and valid, it may be better to specifying that, so that all can point to same requirement.

Just like PUT and PATCH are specialized against target resource in above requirement like PUT or PATCH on a container, we can specialize on interaction-mode in case of POST like POST with ldp::BasicContainer interaction mode.

Otto-AA commented 1 year ago

I agree with @damooo . Allowing folders to have arbitrary contain statements means that applications can't trust this.

Currently, most applications I've checked implicitly trust the contain statements, leading to unexpected behaviour if this is not the case. For instance, several recursive delete methods I've seen simply proceed to delete all contained resources, without checking their urls. If the folder "contains" files with completely different urls, the applications will happily delete them too. This is for sure unexpected behaviour, even with security implications.

We may argue, that it is up to the applications to check this. However, I don't see why we should not add this constraint, as we already have similar constraints for PUT and PATCH. Except of course, that this change would not be backwards compatible and eg ESS would need to change their implementation.