Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parent folder .acl is not consulted, even if local .acl does not specify permissions #29

Closed
angelo-v opened this issue Feb 21, 2020 · 3 comments

Comments

@angelo-v
Copy link

angelo-v commented Feb 21, 2020

Given a folder contains a .acl file specifying permissions to a file inside that folder, but does not say something about permissions to the folder itself:

<#owner>
    a acl:Authorization;
    acl:agent <https://angelo.veltens.org/profile/card#me>;
    acl:accessTo <./file.ttl>;
    acl:mode acl:Read, acl:Write, acl:Control.

The parent folder grants all access for the same agent as default (acl:default)

.
├── .acl # grants all access via `acl:default`
├── acltest
│   ├── .acl # contains the content seen above
│   └── file.ttl

Actual behaviour:

Both, the folder and the file.ttl are unreachable for the agent (403 Forbidden).

Expected behaviour:

Since the .acl does not specify access control for the folder, the parent folder .acl should be checked and access granted to the folder (granted by parent .acl) and to the file.ttl (granted by the folder's .acl).

@kjetilk
Copy link
Member

kjetilk commented Feb 22, 2020

Yes, this has been discussed in the specification, and it is actually the intended behaviour. Here is the spec issue, pointing to timbl's comment on this:
solid/specification#55 (comment)

@kjetilk kjetilk closed this as completed Feb 22, 2020
@angelo-v
Copy link
Author

angelo-v commented Feb 22, 2020

Should'nt at least file.ttl be accessible, since permission is excplicitly granted? Do you know about any specification or NSS improvments, so that ACLs that do not mention the container itself are prevented?

I mean adding at least one acl:accessTo <./> seams to be a must have for a valid container ACL then?

@kjetilk
Copy link
Member

kjetilk commented Feb 22, 2020

It sounds like it could be enforced by a shape to not get into that kind of situation, but other than that, I'm not aware of that.

But please mention the problem in solid/specification#55 so we can look into it in that context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants