Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unsufficient restriction over user supplied containment triples #451

Open
damooo opened this issue Aug 28, 2022 · 3 comments
Open

Unsufficient restriction over user supplied containment triples #451

damooo opened this issue Aug 28, 2022 · 3 comments

Comments

@damooo
Copy link

damooo commented Aug 28, 2022

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
Copy link
Member

csarven commented Aug 31, 2022

[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
Copy link
Author

damooo commented Sep 2, 2022

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
Copy link

Otto-AA commented Mar 21, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants