Node-solid-server: Disallow writing of broken .acl files

[jeff-zucker]

If the user attempts to put/post an .acl file using the wrong content-type or if they have a syntax error in the .acl, the user then loses control of the .acl and whatever it points to. Only a server admin can fix the broken .acl, the user can't edit or delete it.

I think a minimum fix is that the server should cowardly refuse to write an .acl file that has broken syntax or the wrong content-type - allowing users to do this has no benefits and quite terrible consequences - it guarantees that no one except the server admin can access the .acl or the resources it points to.

[jeff-zucker]

Looking at https://forum.solidproject.org/t/is-my-pod-dead, you can see that several users have managed to make their entire pods inaccessible because of this problem.

[scenaristeur]

An example https://github.com/solid/node-solid-server/issues/1376

[jeff-zucker]

This may be too tricky, but the server should also disallow creation of a .acl if it does not grant Control to anyone. As with broken syntax and wrong content-type, an .acl that does not grant Control to anyone becomes unalterable by anyone but a sysadmin.

[kjetilk]

We have a generic issue on this topic in the spec work: https://github.com/solid/specification/issues/67
However, we added RDF validation of ACL files quite some time back, it is surprising if that isn't working anymore.

[melvincarvalho]

Only a server admin can fix the broken .acl, the user can't edit or delete it.

This is not quite correct. Anyone with access to the file system should be able to edit it or delete.

This should actually be all users. The idea of a centralized server admin should be something we would like to make less common, both in thought process, and in reality

This is a practical point as well as theoretical. For most of my Pods I will have access to the file system. Using solid any other way, is for me, a poor mans solid, and IMHO not really giving too much advantage

This can be applied to both the single user and multi user server. For example you can give each solid user a unix user id and login via SSH. This has a number of advantages including allowing you to set a file quota. I do this with node solid server today, and I would hate to use a pod that didnt offer that feature/service at some point. It would be the equivalent of getting a VPS and only access via FTP

[scenaristeur]

Anyone with access to the file system should be able to edit it or delete

So who can unlock my POD ?

[bourgeoa]

As can be seen https://gitlab.com/solid.community/support/issues/4, solid.community has 300 badAcl having a wrong mime-type. The consequence is : it is impossible to access the related folder. That is giving a bad user experience.

I think that NSS should forbid the creation of .acl when the contenType is not text/turtle.

[kjetilk]

Right, checking the media type sounds like a good idea too, we should have that.

[scenaristeur]

Another point but same idea : an app must not be able to revoke the owner and take control of a resource. Because if someone want to test an app, he must be able to get his pod back and be sure to not lost his data. If I don't have the garantie, I don't want to test any app. And noone will

[jaxoncreed]

I wouldn't go as far as to say that in all cases apps should not be able to revoke resource controllers. It might be useful to be able to build access control oriented apps that are able to do this. But, it should be a large barrier that apps need to go through to be able to do this.

[bourgeoa]

At least we need to be sure that an agent has acl: control and if not root acl:control may apply.