CSS seemingly allows PATCH-to-create c/r without acl:Write permissions on c/r (201 instead of 401)

[michielbdejong]

Environment

CSS v4.0.1, node v12.19.1, npm v6.14.8

Description

Save this file as acl.ttl:

@prefix acl: <http://www.w3.org/ns/auth/acl#>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.

<#read-append> a acl:Authorization;
  acl:agentClass foaf:Agent;
  acl:accessTo <http://localhost:3000/>;
  acl:default <http://localhost:3000/>;
  acl:mode acl:Read, acl:Append.

Upload it to http://localhost:3000/.acl by doing:

curl -v -X PUT -H 'Content-Type: text/turtle' -T acl.ttl http://localhost:3000/.acl

Now save this as patch.n3:

@prefix solid: <http://www.w3.org/ns/solid/terms#>.
<#patch> a solid:InsertDeletePatch;
  solid:inserts { <#hello> <#linked> <#world> .}.

and run the following two curl commands:

curl -X PUT -d '<#hello> <#linked> <#world>.' -H 'Content-Type: text/turtle' http://localhost:3000/with-put.ttl
curl -X PATCH -T patch.n3 -H 'Content-Type: text/n3' http://localhost:3000/with-patch.ttl

You will see the first one results in a 401, the second one in a 201, and indeed when you do curl http://localhost:3000/ you see /with-patch.ttl was created and /with-put.ttl was not:

[...]
    ldp:contains <index.html>, <with-patch.ttl>.

And with curl http://localhost:3000/with-patch.ttl you can see the contents:

<#hello> <#linked> <#world>.

Why is this different depending on the verb?

See also solid/web-access-control-spec#105.

[michielbdejong]

Renamed this in the light of the resolution of solid/web-access-control-spec#105 - it now seems clear that the PUT-to-create behaviour is correct in CSS, but the PATCH-to-create behaviour is not.

[michielbdejong]

Also seems to be happening for PUT. This is the ACL (note acl:Write is missing in the second one, that's the point of this test):

    @prefix acl: <http://www.w3.org/ns/auth/acl#>.
    
    <#alice> a acl:Authorization;
      acl:agent <https://solidtestsuite.solidcommunity.net/profile/card#me>;
      acl:accessTo <http://localhost:3000/web-access-control-tests-1656490540430/using-PUT-in-existing-test-test-disallowed-accessTo/>;
      acl:default <http://localhost:3000/web-access-control-tests-1656490540430/using-PUT-in-existing-test-test-disallowed-accessTo/>;
      acl:mode acl:Read, acl:Write, acl:Control.
    <#bobAccessTo> a acl:Authorization;
      acl:agent <https://solid-crud-tests-example-2.solidcommunity.net/profile/card#me>;
      acl:accessTo <http://localhost:3000/web-access-control-tests-1656490540430/using-PUT-in-existing-test-test-disallowed-accessTo/>;
      acl:mode acl:Read, acl:Append, acl:Control.
    <#bobDefault> a acl:Authorization;
      acl:agent <https://solid-crud-tests-example-2.solidcommunity.net/profile/card#me>;
      acl:default <http://localhost:3000/web-access-control-tests-1656490540430/using-PUT-in-existing-test-test-disallowed-accessTo/>;
      acl:mode acl:Read, acl:Append, acl:Write, acl:Control.

And this is the output of some debug statements I added in the CSS code:

Checking if https://solid-crud-tests-example-2.solidcommunity.net/profile/card#me has write,create permissions for http://localhost:3000/web-access-control-tests-1656490540430/using-PUT-in-existing-test-test-disallowed-accessTo/new.txt
checking {
  agent: {
    read: true,
    append: true,
    write: true,
    control: true,
    create: true
  },
  public: {}
} write
checking {
  agent: {
    read: true,
    append: true,
    write: true,
    control: true,
    create: true
  },
  public: {}
} create

Assuming 'create on c/r' (a CSS-specific concept, not a real WAC mode) means 'write on c/', I'm wondering how that got set to true. Digging deeper into the CSS code...

[michielbdejong]

Ah no, it comes from https://github.com/CommunitySolidServer/CommunitySolidServer/blob/v4.0.1/src/authorization/WebAclReader.ts#L169
So like 'delete on c/r', 'create on c/r' is directly implied by 'write on c/r' and just seems to split out create/update/delete.

So the check of permissions on c/r (including consideration of whether c/r already existed) seems to be correct.
The check of permissions on c/ (in case c/r did not yet exist) seems to be missing.
Will have to find how that works for DELETE, then.

[michielbdejong]

The check for permissions on c/r is here:
https://github.com/CommunitySolidServer/CommunitySolidServer/blob/v4.0.1/src/authorization/WebAclReader.ts#L69

[michielbdejong]

So my initial assumption about what 'create' and 'delete' modes mean was correct

[michielbdejong]

so the 'create' flag is used to check append-or-write on c/ but it's not used to check write on c/r
For PUT this is fine, because there write on c/r is already needed. but for PATCH it's not.

[michielbdejong]

Fixed in my fork of CSS. The CSS team have asked not to be contacted so I guess we can't make it into a PR and it will have to stay forked for the time being, unfortunately. Should probably also not call that fork "CSS" then, but come up with some other name for it.