You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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,
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:
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.
The text was updated successfully, but these errors were encountered: