Community Solid Server Access Modes differ from WAC spec

[ianconsolata]

Environment

• Server version: 5.0.0-alpha.0
• Node.js version: v16.17.1
• npm version: 8.15.0

Description

I have set up the following .acl file on a container (at https://mysilio.me/ian/spaces/home/.acl) using the Inrupt libraries in order to grant a default access of Read and Write to all resources in the folder to the https://mysilio.me/mkg/profile/card#me agent.

<#16769073984265129618632307735> a <http://www.w3.org/ns/auth/acl#Authorization>;
    <http://www.w3.org/ns/auth/acl#agent> <https://mysilio.me/mkg/profile/card#me>;
    <http://www.w3.org/ns/auth/acl#mode> <http://www.w3.org/ns/auth/acl#Read>, <http://www.w3.org/ns/auth/acl#Append>, <http://www.w3.org/ns/auth/acl#Write>;
    <http://www.w3.org/ns/auth/acl#default> <https://mysilio.me/ian/spaces/home/>.

However, when I try to modify files in that container with that user, I get a 403, and the server logs show

2023-02-20T15:37:23.687Z [WebAclReader] {Primary} info: Found applicable ACL document https://mysilio.me/ian/spaces/home/.acl
2023-02-20T15:37:23.696Z [PermissionBasedAuthorizer] {Primary} warn: Agent https://mysilio.me/mkg/profile/card#me has no create permissions

The WAC spec only lists 4 Access modes:
https://solidproject.org/TR/wac#access-modes

acl:Read
Allows access to a class of read operations on a resource, e.g., to view the contents of a resource on HTTP GET requests.
acl:Write
Allows access to a class of write operations on a resource, e.g., to create, delete or modify resources on HTTP PUT, POST, PATCH, DELETE requests.
acl:Append
Allows access to a class of append operations on a resource, e.g., to add information, but not remove, information on HTTP POST, PATCH requests.
acl:Control
Allows access to a class of read and write operations on an ACL resource associated with a resource.

And the ACL vocab also has no mention of a create permission: https://www.w3.org/ns/auth/acl

However, the Community Solid Server has one more, create:

CommunitySolidServer/src/authorization/permissions/Permissions.ts

Lines 7 to 13 in bb74278

	export enum AccessMode {
	read = 'read',
	append = 'append',
	write = 'write',
	create = 'create',
	delete = 'delete',
	}

export enum AccessMode {
  read = 'read',
  append = 'append',
  write = 'write',
  create = 'create',
  delete = 'delete',
}

I don't understand what this create permission is for, or how I am supposed to grant it to an agent using the WAC spec. Is this documented anywhere?

[joachimvh]

Internally CSS uses different permissions than WAC but translates between them. delete is another permission that is not in WAC for example, and control is one that it does have, but is not in CSS. Reason being that to, for example, create a new resource in a container WAC requires the user to have write permissions on the new resource, and append permissions on the container. So in CSS internally we convert that to create. It also allows for easier support other authorization systems that might use other terms. Disadvantage is indeed that the log message does not explicitly say what is wrong with your ACL resource. My guess is that in this case you didn't have append permissions on the container.

Unfortunately there is no official table in the spec itself about these interactions. The implementation in CSS is based on this specification comment solid/specification#14 (comment). Here is an issue where I mention that it would be nice to have such an official table: solid/specification#384.

[ianconsolata]

So this is my .acl:

<#16769073984265129618632307735> a <http://www.w3.org/ns/auth/acl#Authorization>;
    <http://www.w3.org/ns/auth/acl#agent> <https://mysilio.me/mkg/profile/card#me>;
    <http://www.w3.org/ns/auth/acl#mode> <http://www.w3.org/ns/auth/acl#Read>, <http://www.w3.org/ns/auth/acl#Append>, <http://www.w3.org/ns/auth/acl#Write>;
    <http://www.w3.org/ns/auth/acl#default> <https://mysilio.me/ian/spaces/home/>.

As far as I can tell, that sets the default access to resources in the container to have Read, Write, and Append -- ah, but I haven't set those on the container itself, just as the default for it's children.

Another strange issue I am having is inheritance related. It's not clear how this should work from the spec, and I haven't been able to find anything on what choices CSS makes here either. In this case, I am trying to grant access to an entire folder to an agent. Inside that folder some files are also accessible to the public, and thus have more specific resource acls.

It seems like, based on the behavior of CSS, that those resource ACLs always take precedence, and are not merged with the parent container ACL when determining permission. Is that correct? Do need to copy those permissions into each resource ACLs in the container? That's quite a lot of work to keep in sync, given how many files we are managing.

[joachimvh]

Ah my apologies, somehow I missed the ACL in the original comment. But yes, to make it work it would also need an acl:accessTo triple in the same block to provide the permissions on the container itself.

It seems like, based on the behavior of CSS, that those resource ACLs always take precedence, and are not merged with the parent container ACL when determining permission. Is that correct?

That is how WAC works yes. You can find the algorithm at https://solidproject.org/TR/wac#effective-acl-resource. In v6 CSS will also have support for ACP, an alternative authorization method to WAC, and that one does merge all the parent permissions together.

The easiest solution in WAC is to put all resources that should also be publicly accessible in a subcontainer so you only need to have 1 ACL for that container then.

[ianconsolata]

The spec also says "Alternative strategies such as cumulative permissions (union of all the permissions from each ACL resource inherited from the ancestors of a resource) are allowed, but no behaviour is defined by this specification" (https://solidproject.org/TR/wac#permission-inheritance-extensions), so I wasn't sure exactly what the intended implementation here was.

[joachimvh]

Ah, I didn't even know that section was in there. But no, CSS does the strict effective resource detection described in the spec.