What does write access to a container mean?

[michielbdejong]

On a container, I think:

• acl:Read means you can list the container members ('GET')
• acl:Append means you can add new resources into it ('POST')
• acl:Control means you can create, update or delete that container's ACL document
• acl:Write means you can do 'DELETE' on that container

For starters, it's not clear to me from the LDP spec whether deleting a container also deletes its members.

But apart from that, it's not clear to me from the WAC spec whether deleting a container also deletes its ACL document (especially since editing the ACL document without acl:Control access should be impossible, right?)

Related to nodeSolidServer/node-solid-server#1179

[RubenVerborgh]

* `acl:Write` means you can do 'DELETE' on that container

Correction: means DELETE on resource inside of that container.

[michielbdejong]

DELETE on resource inside of that container.

Oh, that's not how I read the current spec text. Where is that documented and/or implemented?

[RubenVerborgh]

• Deleting a file should require write permission on the container nodeSolidServer/node-solid-server#729
• Deleting a file should require write permission on the container solid-contrib/solid-permissions#28
• Make DELETE require write permissions on container nodeSolidServer/node-solid-server#1014

[michielbdejong]

Thanks for the link, slightly shocking that that remark from @dmitrizagidulin about "this should be a spec-level discussion" was just ignored there. I created #47 about it now, so we can discuss that there.

That does bring me back to the original two points of this issue - when deleting a container, should the ACL doc be deleted, and should members and sub-members be deleted?

[RubenVerborgh]

"this should be a spec-level discussion" was just ignored there

Told you, the spec has massively been neglected, cfr. https://lists.w3.org/Archives/Public/public-solid/2019May/0015.html:

The "Solid spec" (however we frame it) wasn't intended to be above and beyond documenting a rough understanding and expectations to enabling the Solid ecosystem. So, nothing was written in stone and it only reflected what we arrived at with part implementations.

So definitely something that needs to be adjusted indeed.

That does bring me back to the original two points of this issue - when deleting a container, should the ACL doc be deleted, and should members and sub-members be deleted

The intention was to not do an rm -rf. In principle, if we are really strict with Cool URIs, a container deletion should result in a tombstone such that the same container can never be created again. But that obviously goes way too far for practical purposes.

I would argue that all deletions need to be manual. This does require visibility of the .acl file though.

In no circumstance should a user without Control permissions be able to cause the deletion of an .acl file, in whatever way.

[michielbdejong]

OK, so conclusion:

• acl:Write on a container means you can do 'DELETE' on that container
• see also a proposed spec change in [discuss] should we switch to requiring container-write instead of resource-write permissions for delete? #47
• if the container contains anything other than a .meta, the delete operation will fail
• so that includes, if a .acl document exists in a container, the delete operation will fail
• we should document this

[michielbdejong]

Resolved, created #48 for the last point.