Feature: add tests for 'Control'

[ylebre]

The spec mentions that .acl files should only be accessible for a webId with "Control" access, but there are no tests to validate that.

[ylebre]

Another check is that the Link header to the .acl is only sent when the user has Control grants.

[bourgeoa]

Another check is that the Link header to the .acl is only sent when the user has Control grants.

is it in the actual spec
NSS do not do the check

[ylebre]

Oof this is a while ago. It was mentioned in the chat that this was the case. I think the reasoning was this part of the spec:

acl:Control

is a special-case access mode that gives an agent the ability to view and modify the ACL of a resource.

This was understood to also imply that if one does not have Control, they would not need to know where the .acl file resides either.

[ylebre]

I dug op the conversation from the solid/chat gitter that I got this from for more background, though after re-reading the spec I can't say that I can find a specific mention about not having the Link. I'll try to get some more specifics about that!

@ylebre

question: when fetching a resource that has a .acl Link in the header, what .acl is that pointing to? Should that be the .acl file that is active on that resource? Or a suggestion on where to find a .acl file, if any? If it is the active resource, it would probably point to something above the current resource, which makes it hard to use a relative path for it

As far as I understand the WAC spec (https://solid.github.io/web-access-control-spec/#acl-resource-location-discovery), the Link header mentions the .acl file, that describes the access control for its corresponding and specific resource. If there is no such specific .acl file, inheritance kicks in (https://solid.github.io/web-access-control-spec/#acl-resource-location-discovery).
So, looking at the spec, it seems that the Link header should NOT point to a more general (parent) .acl file, but rather point to a non existing .acl file... and require the client to do the legwork in finding the applying .acl...
But maybe the spec is not the bible and others have better knowledge of the current status...

@timbl

The spec is the spec is right
It points to the ACL file for that particular resource which may be 404

@ylebre

thanks!

@csarven

Is there a way to make .acl files publically accessible (for read)?

Bear with me..
Short answer as per Solid Protocol + WAC, no, server must not expose the URL of the ACL resource or make the ACL resource readable to agents without Control access on the resource that the ACL resource is directly associated with. A server could do it but it would violate the spec. Leaks authorization policies to unauthorized agents eg. I could get to know who has what access to a resource even if I don't have any or limited access to it myself.
Having said, and as Tim mentioned, the WAC-Allow header is used to address the underlying use case ie. client wants to determine what access privileges they might have (as well as the public). The header only reveals a safe subset - which is a shortcut available to a client where they could potentially find out if they were to make HTTP requests with different methods (including authenticated and unauthenticated).

[ylebre]

As for the tests, I'm thinking we need a couple of entries to cover the base case:

User with Control receives the Link header pointing to the .acl location
User with Read+Write, without Control does not get the Link header

User with Control can read the .acl file
User with Read+Write, without Control can not read the .acl file

User with Control can modify the .acl file using PUT/PATCH
User with Read+Write, without Control cannot modify the .acl file

Do you think that would cover it?

[ylebre]

Here is the relevant piece of the spec:

https://solidproject.org/TR/protocol#auxiliary-resources-web-access-control

To discover, read, create, or modify an ACL auxiliary resource, an acl:agent MUST have acl:Control privileges per the ACL inheritance algorithm on the resource directly associated with it.

[ylebre]

PR here: #37