ACL read access not working

[hendrikbecker99]

Hi everyone,

I am using an Inrupt POD and try to update ACL files of ressources to give other users read access to the ressource.

My issue:
Updating the ACL file with read access for another user does not lead to read access. The other user will still receive a 403 error
when trying to access the ressource.
Once I give the other user control access rights as well, the other user can access the file.

I provide an example below. I hope someone has an idea on how to approach that issue!

Kind regards
Hendrik
AccessControlIssue.txt

[uvdsl]

Hi,
I looked into this and found three points worth mentioning:

(1) Use relative URI in ACRs

Apparently, in the Access Control Rule (ACR) that provides a specific user with read access to a resource, that resource must not be referenced as an absolute URI but by relative URI. Otherwise the rule is not recognized by the NSS.

@prefix acl: <http://www.w3.org/ns/auth/acl#>.

<#owner> a acl:Authorization;
    acl:agent <https://viktor.solid.aifb.kit.edu/profile/card#me>;
    acl:accessTo <https://viktor.solid.aifb.kit.edu/private/Credential.txt>; # THIS DOES WORK
    acl:mode acl:Read, acl:Write, acl:Control.
<#Read> a acl:Authorization;
    acl:accessTo <https://hans.solid.aifb.kit.edu/private/Credential.txt>; # THIS DOES NOT WORK
    acl:agent <https://hans.solid.aifb.kit.edu/profile/card#me>;
    acl:mode acl:Read.
<#Read2> a acl:Authorization;
    acl:accessTo <./Credential.txt>; # THIS DOES WORK
    acl:agent <https://uvdsl.solid.aifb.kit.edu/profile/card#me>;
    acl:mode acl:Read.

If we change the object of <#Read2> acl:accessTo <./Credential.txt>. to be an absolute URI, e.g. <https://hans.solid.aifb.kit.edu/private/Credential.txt>, we get the following logs:

2022-03-04T14:51:43.212Z solid:ACL Using ACL https://viktor.solid.aifb.kit.edu/private/Credential.txt.acl for ./Credential.txt
2022-03-04T14:51:43.213Z solid:ACL    1 direct authentications about <https://viktor.solid.aifb.kit.edu/private/Credential.txt>
2022-03-04T14:51:43.222Z solid:ACL accessDenied: checking access to <https://viktor.solid.aifb.kit.edu/private/Credential.txt> by <https://uvdsl.solid.aifb.kit.edu/profile/card#me> and origin <https://uvdsl.solid.aifb.kit.edu>
2022-03-04T14:51:43.222Z solid:ACL    1 direct authentications about <https://viktor.solid.aifb.kit.edu/private/Credential.txt>
2022-03-04T14:51:43.223Z solid:ACL    Checking auth <https://viktor.solid.aifb.kit.edu/private/Credential.txt.acl#owner> with agent <https://uvdsl.solid.aifb.kit.edu/profile/card#me>
2022-03-04T14:51:43.223Z solid:ACL     Agent or group access fails for this authentication.
2022-03-04T14:51:43.223Z solid:ACL      The agent/group check fails
2022-03-04T14:51:43.223Z solid:ACL       Check failed: User Unauthorized
2022-03-04T14:51:43.223Z solid:ACL accessDenied: modeURIorReasons: ["User Unauthorized"]
2022-03-04T14:51:43.223Z solid:ACL  checking <http://www.w3.org/ns/auth/acl#Read>
2022-03-04T14:51:43.223Z solid:ACL   MODE REQUIRED NOT ALLOWED: <http://www.w3.org/ns/auth/acl#Read> Denying with User Unauthorized
2022-03-04T14:51:43.224Z solid:ACL Read access denied to https://uvdsl.solid.aifb.kit.edu/profile/card#me: 403 - User Unauthorized
2022-03-04T14:51:43.224Z solid:server Error page because of: [HTTPError: User Unauthorized] { status: 403 }
2022-03-04T14:51:43.224Z solid:server Display no-permission for https://viktor.solid.aifb.kit.edu/private/Credential.txt
2022-03-04T14:51:53.214Z solid:cache Cache is empty again

Meaning that neither <#Read> nor <#Read2> are recognized. This is odd because <#owner> is recognised. I believe @hendrikbecker99 found that granting control rights also resolved the problem of ACRs not being recognised with absolute URIs. (Maybe someone can confirm that.)
But with the relative URI we get:

2022-03-04T15:01:30.146Z solid:ACL Using ACL https://viktor.solid.aifb.kit.edu/private/Credential.txt.acl for ./Credential.txt
2022-03-04T15:01:30.146Z solid:ACL    2 direct authentications about <https://viktor.solid.aifb.kit.edu/private/Credential.txt>
2022-03-04T15:01:30.159Z solid:ACL accessDenied: checking access to <https://viktor.solid.aifb.kit.edu/private/Credential.txt> by <https://uvdsl.solid.aifb.kit.edu/profile/card#me> and origin <https://uvdsl.solid.aifb.kit.edu>
2022-03-04T15:01:30.159Z solid:ACL    2 direct authentications about <https://viktor.solid.aifb.kit.edu/private/Credential.txt>
2022-03-04T15:01:30.159Z solid:ACL    Checking auth <https://viktor.solid.aifb.kit.edu/private/Credential.txt.acl#owner> with agent <https://uvdsl.solid.aifb.kit.edu/profile/card#me>
2022-03-04T15:01:30.160Z solid:ACL     Agent or group access fails for this authentication.
2022-03-04T15:01:30.160Z solid:ACL      The agent/group check fails
2022-03-04T15:01:30.160Z solid:ACL       Check failed: User Unauthorized
2022-03-04T15:01:30.160Z solid:ACL    Checking auth <https://viktor.solid.aifb.kit.edu/private/Credential.txt.acl#Read2> with agent <https://uvdsl.solid.aifb.kit.edu/profile/card#me>
2022-03-04T15:01:30.160Z solid:ACL     Agent explicitly authenticated.
2022-03-04T15:01:30.161Z solid:ACL      Origin check FAILED. Origin not trusted.
2022-03-04T15:01:30.161Z solid:ACL       Check failed: Origin Unauthorized
2022-03-04T15:01:30.161Z solid:ACL accessDenied: modeURIorReasons: ["User Unauthorized","Origin Unauthorized"]
2022-03-04T15:01:30.161Z solid:ACL  checking <http://www.w3.org/ns/auth/acl#Read>
2022-03-04T15:01:30.161Z solid:ACL   MODE REQUIRED NOT ALLOWED: <http://www.w3.org/ns/auth/acl#Read> Denying with User Unauthorized
2022-03-04T15:01:30.161Z solid:ACL Read access denied to https://uvdsl.solid.aifb.kit.edu/profile/card#me: 403 - User Unauthorized
2022-03-04T15:01:30.161Z solid:server Error page because of: [HTTPError: User Unauthorized] { status: 403 }
2022-03-04T15:01:30.161Z solid:server Display no-permission for https://viktor.solid.aifb.kit.edu/private/Credential.txt

Now, <#Read2> is recognized. However, the logs point to the second issue.

(2) The app origin must be a trusted app by the user whose data is being accessed.

I used my test-app to access the resource, but the resource providing user did not list the app as a trusted app. Thus, the request is dropped. The internal mashlib browser interface does work because it is trusted by default (i guess) as it comes from the same domain as the pod is hosted at.

After adding the test-app as a trusted app, i.e. acl:trustedApp in the providing user's profile card, I could retrieve the resource. But there is a catch, see (3).

(3) Failed Content Negotiation results in 500 Internal Server Error

I tried to retrieve a .txt file. My app, however, asks for text/turtle via the accept header by default. (Yes, that may be a design flaw of my app, but I usually only talk turtle anyway, so it is fine for me.) The Pod server tries to convert plain text to turtle and fails ungracefully:

2022-03-04T15:05:06.775Z solid:ACL    2 direct authentications about <https://viktor.solid.aifb.kit.edu/private/Credential.txt>
2022-03-04T15:05:06.775Z solid:ACL    Checking auth <https://viktor.solid.aifb.kit.edu/private/Credential.txt.acl#owner> with agent <https://uvdsl.solid.aifb.kit.edu/profile/card#me>
2022-03-04T15:05:06.775Z solid:ACL     Agent or group access fails for this authentication.
2022-03-04T15:05:06.775Z solid:ACL      The agent/group check fails
2022-03-04T15:05:06.776Z solid:ACL       Check failed: User Unauthorized
2022-03-04T15:05:06.776Z solid:ACL    Checking auth <https://viktor.solid.aifb.kit.edu/private/Credential.txt.acl#Read2> with agent <https://uvdsl.solid.aifb.kit.edu/profile/card#me>
2022-03-04T15:05:06.776Z solid:ACL     Agent explicitly authenticated.
2022-03-04T15:05:06.776Z solid:ACL      Origin might have access (<http://www.w3.org/ns/auth/acl#Append>, <http://www.w3.org/ns/auth/acl#Control>, <http://www.w3.org/ns/auth/acl#Read>, <http://www.w3.org/ns/auth/acl#Write>)
2022-03-04T15:05:06.776Z solid:ACL       Mode allowed: <http://www.w3.org/ns/auth/acl#Read>
2022-03-04T15:05:06.776Z solid:ACL accessDenied: modeURIorReasons: ["User Unauthorized","http://www.w3.org/ns/auth/acl#Read"]
2022-03-04T15:05:06.776Z solid:ACL  checking <http://www.w3.org/ns/auth/acl#Control>
2022-03-04T15:05:06.776Z solid:ACL   MODE REQUIRED NOT ALLOWED: <http://www.w3.org/ns/auth/acl#Control> Denying with User Unauthorized
2022-03-04T15:05:06.776Z solid:ACL Permissions on https://viktor.solid.aifb.kit.edu/private/Credential.txt for https://uvdsl.solid.aifb.kit.edu/profile/card#me: read
2022-03-04T15:05:06.776Z solid:ACL Permissions on https://viktor.solid.aifb.kit.edu/private/Credential.txt for public: 
2022-03-04T15:05:06.777Z solid:get /private/Credential.txt on viktor.solid.aifb.kit.edu
2022-03-04T15:05:06.777Z solid:handlers GET -- Reading /opt/solid/data/viktor.solid.aifb.kit.edu/private/Credential.txt
2022-03-04T15:05:06.779Z solid:get error translating: /private/Credential.txt text/plain -> text/turtle -- 500 Don't know how to parse text/plain yet
2022-03-04T15:05:06.779Z solid:server Error page because of: [HTTPError: Error translating between RDF formats] { status: 500 }
2022-03-04T15:05:16.669Z solid:cache Cache is empty again

I can imagine this behaviour to be intended, i.e. the server can't handle your request, but on the other hand, clearly the client is at fault here. Therefore, I would have expected a 4xx error. (But I am not that experienced with the specifics of HTTP error codes).
When accessing a .ttl resource instead (or some resource where a turtle representation exists) I get no error.

---

Bottom Line

(1) Use relative URIs in ACRs as absolute URIs may not be recognised.
(2) The user providing the resource must trust the accessing agent's app as well.
(3) Keep the mime-types and data formats in mind.

I do not know if the relative URI vs absolute URI in ACRs has been discussed before... I hope this is helpful :)

[bourgeoa]

(1) an ACL resource is attached to a Resource (container, document).
This Resource is defined by a URL. The acl:accessTo and acl:default predicate link to the Resource URL absolut/relative to pod or document.
In your case the triple Object can be :

• https://viktor.solid.aifb.kit.edu/private/Credential.txt
• </private/Credential.txt>
• <Credential.txt> or </Credential.txt>

So your Read ACL rule is wrong (do not link to the correct resource) (I don't think ACR acronym is ever used)

Relative url's are preferred for readability, reusability and ,...

(2) correct and returns 403

(3) a resource is composed of a body and a contentType. Your code should catch for an RDF contentType which is not dependent with the apparent mimeType extension of the Resource.

[uvdsl]

Thanks for your comments!

(1) ah, of course, that was a mistake on my side (copy & paste). Now, the absolute URI also works at my NSS.

(2) strange, I get a 403 User Unauthorized if I remove the trusted app origin in the profile of the user whose Pod serves the resource. (Which I can imagine an argumentation for) But, why should that return a 301 Moved Permanently?

(3) Yup, thank you! Will implement it when I have some time...

[bourgeoa]

Sorry modified to 403.

[bourgeoa]

closed.
You can reopen if you think it is not resolved

[hendrikbecker99]

@bourgeoa Many thanks for the help! My application is now working as desired.