Users with only acl:Append permission are able to POST ACL files

[angelo-v]

Actual behaviour

Given a container where I have acl:Append permission, but no acl:Control permission
When I POST a file to the container using a Slug header ending with .acl
Then the resource gets created and is considered as a valid ACL

Expected behaviour

Creating ACL resources is only possible with acl:Control permission

Example

Container at path /foo with public write permission containing a resource bar.ttl

Request to create an ACL file for bar.ttl:

POST /foo HTTP/1.1
Content-Type: text/turtle
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Slug: bar.ttl.acl

# ACL content

[csarven]

It is only "considered as a valid ACL" because of the automatic relation with a URI template that's in use (which happens to match the created resource) ie. id acl id.acl.

If bar.ttl exists and has rel=acl to bar.ttl.acl, I agree that this is an NSS bug and it should reject the request to create bar.ttl.acl from user with acl:Append - if it didn't do anything about the Slug suggestion. If it did, then it'll just rename to something "safe".

If however bar.ttl doesn't exist, bar.ttl.acl should be handled as any RDF source - not to be "considered as a valid ACL" unless of course if NSS reserves .acl suffix in resource names for "valid ACL"s. So, it shouldn't allow bar.ttl.acl to be created where it can potentially be linked from bar.ttl.

[justinwb]

If however bar.ttl doesn't exist, bar.ttl.acl should be handled as any RDF source - not to be "considered as a valid ACL" unless of course if NSS reserves .acl suffix in resource names for "valid ACL"s.

I don't think it should be handled as any RDF source. The association of a given resource R to an acl resource A in NSS is based on the presence of '.acl' at the end of a A's name, when the part before the .acl in A's name is the same name as R. If A's name is just '.acl', it would apply to the container that A is a member of.

Consider the creation of a resource named 'foo' in container C. If NSS doesn't ensure that there isn't a foo.acl in C first, anyone that can predict that a file named foo will be created at some point can set the permissions in advance by making foo.acl, even if they don't have control permission on container C.

IMO - the simplest path would be for NSS to reserve the .acl suffix to avoid this. Note this is an NSS problem, not a Solid problem. In Solid you can make any resource names you want, and the server maintains the association of acls. It is how NSS maintains that association that leads to this potential issue.

[csarven]

..unless..
So, it shouldn't allow bar.ttl.acl to be created where it can potentially be linked from bar.ttl.

[csarven]

Fixed by #1419. @angelo-v @justinwb et al, can you also verify?

[scenaristeur]

Hi Guys,
Yesterday I was able to use @jeff-zucker https://github.com/jeff-zucker/solid-file-client to create folders & files .acl but
Today I can't & got a Http 500 ERROR, so i'would like to know if that new fix could be the source of my "BMSE" ( Bad Mistake Search Evening) ???

by default, I have CONTROL to the folder & want to add Authenticated Agents as Submitter (https://spoggy-test.solid.community/public/shighl_test/inbox/)

Here is the code I use

let inbox = "https://spoggy-test.solid.community/public/shighl_test/inbox/"
    let aclInboxContent = `@prefix : <#>.
    @prefix acl: <http://www.w3.org/ns/auth/acl#>.
    @prefix inbox: <./>.
    @prefix c: </profile/card#>.

    :Append
    a acl:Authorization;
    acl:accessTo <./>;
    acl:agentClass acl:AuthenticatedAgent;
    acl:default <./>;
    acl:mode acl:Append.
    :ControlReadWrite
    a acl:Authorization;
    acl:accessTo <./>;
    acl:agent c:me;
    acl:default <./>;
    acl:mode acl:Control, acl:Read, acl:Write.
    :Read
    a acl:Authorization;
    acl:accessTo <./>;
    acl:default <./>;
    acl:mode acl:Read.`

    let file = inbox+".acl"
    await fc.createFile (file, aclInboxContent, "text/turtle") .then (success => {
      this.log = "Created "+file
    }, err => {
      this.log = err
      alert(err)
    });

```
here is the app i'm working on https://scenaristeur.github.io/agora/
thxs

[jeff-zucker]

It would be relevant to know what content-type you specified in the PUT request that generated the 500 error.

[scenaristeur]

@jeff-zucker
"text/turtle"

await fc.createFile (file, aclInboxContent, "text/turtle") 

That worked yesterday. Can you create an .acl file today with solid-file-client on a solid.community pod?

[bourgeoa]

Can you try to do it manually using dataBrowser.
I have done it and it works. If you put your resource address .../inbox/.acl in the dataBrowser you can display the acl content with the text edit icon.

Your acl is wrong prefix foaf: is missing, you are using prefix acl: in lieu of prefix foaf:

You are also missing in Read block acl:agentClass foaf:agent

[scenaristeur]

@bourgeoa sure if I want that the inbox can be read by everyone, i need foaf:agent...
but i general, this is not expected ;-)

I want

so the .acl should be

But my question is does this fix could have any influence to the @jeffz solid-file-client putting .acl or not ? As I said there was no matter yesterday to put that file... Is there a server where that patch has not been applied so i could test ?
Does anyone achieve to put an .acl file after the patch with solid-file-client ?

[scenaristeur]

@jeffz here you can test how I try to create .acl with solid-file-client https://scenaristeur.github.io/agora/acl_test.html
here is my test code https://github.com/scenaristeur/agora/blob/gh-pages/acl_test.html
I think that worked two days ago but maybe i'm wrong ?

[scenaristeur]

confirmed by the same test on @bourgeoa server that did not apply the last patch .
Using solid-file-client
On solid.community : PUT file.ttl -> OK & PUT file.ttl.acl -> KO (but was OK 2 days ago)
On @bourgeoa server : PUT file.ttl -> OK & PUT file.ttl -> OK
So that patch block solid-file-client to write .acl file