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

request for clarification: access to resources in container you don't have access to #59

Closed
zenomt opened this issue Jun 16, 2019 · 2 comments
Assignees

Comments

@zenomt
Copy link

zenomt commented Jun 16, 2019

on its face, the spec implies that a resource can have an individual ACL that can grant access even if the user doesn't have access to traverse through container(s) to where the resource is. specifically:

For fine-grained control, users can specify a set of permissions for each individual resource (which overrides any permissions of its parent container).

ACL Inheritance Algorithm...

in other words, there could be a resource in a container (maybe several levels deep) where the user has no access on the containers at all, but an acl on the resource could punch a hole to allow access (you could also imagine it as a wormhole or quantum tunneling).

it makes more sense to me that a user should at least have read permission to all containers down to the resource in order to access the resource. this is consistent with the Unix directory model (although in Unix you just need the "search" (via the "execute" bit) permission to traverse a directory, and the "read" permission to list its contents, but there's no distinct "search" in WAC).

if the "hole punch/wormhole/tunnel" semantics is intentional, please call it out as intentional, as it is surprising and inconsistent with peoples' normal experience and intuition with containers/folders/directories. otherwise if this case is an oversight, please correct it.

in my own implementation of WAC, any access of a resource requires read permission for all containers down to the resource, plus the required permission for the resource access itself.

@RubenVerborgh
Copy link
Contributor

on its face, the spec implies that a resource can have an individual ACL that can grant access even if the user doesn't have access to traverse through container(s) to where the resource is.

Correct.

it makes more sense to me that a user should at least have read permission to all containers down to the resource in order to access the resource. this is consistent with the Unix directory model

Yes, but the Web is not Unix, in the sense that resources are just things with URLs. The concept of a directory is not needed to access one specific resource. (It only becomes needed when you traverse links to its parents etc., to which you might or might not have access.)

if the "hole punch/wormhole/tunnel" semantics is intentional, please call it out as intentional,

Good idea.

@csarven
Copy link
Member

csarven commented Jul 8, 2021

Closing this issue as consensus is deemed to be captured in WAC Editor's Draft: https://solid.github.io/web-access-control-spec/ . See #access-objects #effective-acl-resource

@csarven csarven closed this as completed Jul 8, 2021
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

3 participants