Which permissions are required for deleting a resource?

[RubenVerborgh]

[csarven]

If LDP's behaviour is applied to R and C: Write permissions on R as well as C is required in order to remove the containment triple from C. This requirement can be derived from LDP's DELETE: https://www.w3.org/TR/ldp/#ldpc-del-contremovesconttriple

[kjetilk]

What if we end up with rm -r (#190)? Then, it would need to be write on all resources down to and including the container?

[csarven]

I'd like to clarify https://github.com/solid/solid-spec/issues/195#issuecomment-559619352 because of a subtle point related to this issue. With the given that containment triples are server-managed, while Write is required on R, Write is not explicitly required on C for the purpose of removing the containment triple. There is an implicit write operation on C based on LDP's interaction model (when R is removed from containment triples) but that burden is not placed on the requesting agent, hence their access to C can be seen as out of scope. However, as LDPR's lifecycle is dependent and controlled by the LDPC in which it has a binding relationship with, it can be expected that any changes to that binding should require permission to alter C.

What's argued is more of a design decision based on connecting some basic assumptions. AFAICT, requiring Write on C and R in order to delete R is compatible with *nix behaviour.

[csarven]

What if we end up with rm -r (#190)? Then, it would need to be write on all resources down to and including the container?

If rm -r is analogous, then it'd be reasonable to consider whether -f is applied by default as well ie. no prompt.

[Aside:

• I'm not sure whether --one-file-system applies to our design. Revisit. Already discussed elsewhere.
• --preserve-root is taken as given in that ACL document R of root C can't be deleted.
• -d is used provided that a C is considered to be "empty" if its auxillary resources like acl and possibly meta doesn't count towards it.

]

Having -f as the default would be the simplest design - not to imply ideal - as opposed to for example having a workflow which prompts the user per child resource that's encountered along the way. -I may be useful in that there is some sort of a signal given back to the client (eg. can't delete C or need to delete contained C because it contains R).

In any case, rm -r should be treated as atomic. On *nix, user is only prompted if need to ie. all other removes will succeed.

[kjetilk]

Yeah, I think the attractiveness of rm -r is atomicity, which is hard to achieve for multiple HTTP requests.

As for -f, just a wild thought, it is not so much the prompt that I think characterizes -f but that you can delete a file if you would have permission to do so if you changed the permissions on the file and you have permission to do so... Which wasn't particularly clear, I suppose, but the wild thought I had was, perhaps acl:Control has a role to play...?

[csarven]

Edit: As of this writing, the text in spec says ( as per PR #188 ) based on #197 (comment) (which was one possible approach) :

To delete a resource, an acl:agent MUST have acl:Write privilege per the ACL inheritance algorithm on the resource and the containing container.

The counter argument below indicates why it'd be preferable to not require Write on the container of the contained resource. It would prevent over permissioning and easier policy management.

---

By not requiring Write on container to delete a contained resource, agents are not granted more access than what they need. Granting an agent with Write on container allows them to modify the container description, potentially modify or delete all contained resources, as well as delete the container.

Use case being that a user needs to create resources in a container where they can then work on the created resource ie. read, update, delete. They don't need to have knowledge or access to anything else in that container, including the container itself.

To put it generally, it is possible for a container and contained resources to have different authorization policies. Example code snippets:

### container's ACL:

<#container-policy>
  acl:accessTo <./> ;
  acl:agentClass foaf:Agent ;
  acl:mode acl:Append ;

<#contained-resources-by-default-read-policy>
  acl:default <./> ;
  acl:agent <http://example.org/the-oracle#i> ;
  acl:mode acl:Read .

<#contained-resources-by-default-control-policy>
  acl:default <./> ;
  acl:agentGroup <http://example.org/the-architect-and-friends#i> ;
  acl:mode acl:Control .

### a contained resource's ACL:

<#contained-resource-policy>
  acl:accessTo <./contained-resource> ;
  acl:agent <http://example.org/agent-smith#i> ;
  acl:mode acl:Read, acl:Write .

Then, Agent Smith should only need Write to delete a contained resource.

[RubenVerborgh]

+1 from me

[michielbdejong]

Yeah, I guess both options make sense, but your argument for changing this are convincing. If you have write on R then you can already set it to zero bytes anyway, which is almost the same as deleting it. It's a bit weird that you end up affecting the container's contents without having explicit permission to change it, but that's probably unavoidable.

Since it reduces the required permissions, it will not break many clients. But this is a semver-major change, so I'll change the behaviour in NSS 6.

I hadn't added any tests for this in https://github.com/solid/web-access-control-tests yet, so I'll immediately create the tests to test the new behaviour.

[acoburn]

+1 on not requiring acl:Write on the container in order to allow deletion of a contained resource (assuming the agent has acl:Write permission on the contained resource).