Explain the ACL inheritance algorithm for clients

[RubenVerborgh]

[dmitrizagidulin]

Why not have the server specify the inherited ACL in a header? Figuring out the parent acl is something the server does on almost every request, it’s a core capability.
Why have the client make all these http requests?

[kjetilk]

I agree, we should have a Link to that as well. Note, however, that this issue is about the client's use of the inheritance mechanism, and the client should only need to find that on writes, otherwise it is the server's job to enforce this. This was an insight @timbl gave us yesterday.

[zenomt]

other than specially-privileged permission management apps that have acl:Control, what clients need to know a resource's ACL URI?

for a parent/inherited ACL, it might be of interest to know its URI, but you'd presumably also want to know the URI of the parent container it goes with (it could be several levels up), so that if you were a permission management app, the user could make an informed decision as to how to appropriately adjust that container's permissions.

i hope and expect it'll be rare for random apps/clients to have acl:Control permission for any resources, particularly because it'll be Hard for random apps to understand and apply the user's potentially complex access policy intentions.

[csarven]

[Revisiting this proposal even though I was in the original meeting for it.]

We currently have consensus on the following:

• Server associates an ACL to a resource. There is no URI template for an ACL that a server needs to apply. The only implied requirement is due to hierarchical nature of the resources ie. if a resource doesn't have its own ACL, its parent container's ACL is applied (repeat going up the hierarchy until root container/Storage's ACL is findable). So eg. /foo/bar 's ACL can be /foo/bar.acl , /foo/.acl , /.acl , but not /baz/qux.acl or /baz/.acl.

• Control access privilege on a resource is required in order to discover its ACL.

Hence, it is currently possible for a server to return the effective/inherited ACL of a resource. No algorithm required for a client other than to check rel=acl in resource's Link header.

Aside: If I'm not mistaken, there is a historical reason to why the inheritance algorithm exists... It is partly due to the way NSS worked - it happened to automatically associate an ACL to each resource - whether that ACL actually existed as an independent resource or one determined based on an inheritance algorithm was another matter. From that point, we can see why the inheritance algorithm would be required.

Proposal: Unless there are security implications we should consider, servers MUST only return the effective ACL for a given resource ie. Link rel=acl as advertised. No new requirements needed for clients.

[acoburn]

servers MUST only return the effective ACL for a given resource

How can a client then know how/where to PUT the specific ACL?

In fact, it is worse. If a client treats URIs as opaque, believing that the effective ACL applies only to a particular resource (when in fact it applies to an entire hierarchy of resources), doing a PUT or PATCH on that (effective) ACL resource will affect the ACLs of every other resource that currently inherits from that ACL. Imagine if the effective ACL is the root resource and a client really only wanted to change the ACL of a single child resource.

This is fine if that is the intention of a client, but if there is no way of knowing whether such an operation will affect one resource or many resources then the security implications of that change will be terrible.

[csarven]

As mentioned, shared slash semantics and hierarchical paths limit the possibilities eg. "/foo/bar 's ACL can be /foo/bar.acl , /foo/.acl , /.acl , but not /baz/qux.acl or /baz/.acl."

If a client wants to PUT a specific ACL for /foo/bar, it'll have to be under /foo/ or / (but not any other branch).

[acoburn]

shared slash semantics and hierarchical paths limit the possibilities

You are building a security model on apriori knowledge of this by every current and future client.

[csarven]

That knowledge is already required by the spec. Figured that what's possible stems from that.

Rethinking this.. the issue is not so much of PUTing an ACL but that of associating an ACL with a resource. So, I'm okay to put a pause on that proposal :) It was just another way of not requiring clients to hunt down an ACL or having a server expose yet-another location for an ACL (the "actual" and the "effective")

Edit: associating an ACL to a resource can be done with the LINK method provided that the target location is allowed.

[csarven]

If a client treats URIs as opaque,

That conflicts with the requirement for clients and servers sharing the slash semantics in URI path. Can't expect clients to conform to that as well as decide to treat URIs as opaque entirely. The latter is currently out of spec behaviour, unless of course exceptions to the requirement are introduced.

believing that the effective ACL applies only to a particular resource (when in fact it applies to an entire hierarchy of resources), doing a PUT or PATCH on that (effective) ACL resource will affect the ACLs of every other resource that currently inherits from that ACL. Imagine if the effective ACL is the root resource and a client really only wanted to change the ACL of a single child resource.

This is fine if that is the intention of a client, but if there is no way of knowing whether such an operation will affect one resource or many resources then the security implications of that change will be terrible.

True and those are valid concerns. Note however that updating an ACL policy containing acl:accessTo <./> and acl:default <./> by definition affect the resources relying on them. Client must be able to understand accessTo, default, among other things in order to do anything with them in the first place. This holds true for all clients updating ACLs.

I do however see another issues with "servers MUST only return the effective ACL for a given resource":

---

What's on the table:

• Clients use the inheritance algorithm to discover a resource's inherited ACL.
• Servers advertise a resource's inherited ACL independently of its specific ACL.

What's attractive about the client figuring out the inherited/effective ACL is that once a container with an ACL is found, the relation between the container resource and its ACL is clear in conjunction with the policy descriptions in container's ACL.

That clarity is lost if "servers MUST only return the effective ACL for a given resource" ie. Resource rel=acl ACL, but when clients read that ACL's policies, relative paths for the values of accessTo and default can potentially mislead the client. Hence, a different link relation (eg using acl:inheritedACL) is needed to make the distinction from rel=acl with a different understanding on handling the inherited ACL.

The two approaches are not mutually exclusive (provided that they yield the same ACL). Clients are generally capable of using the inheritance algorithm given the base requirements (Aside: note also the similarity to traversing the URI path to find the controller of a storage as proposed in #153 (comment) and there are some ways to optimise the checks). Servers using two different relations for ACLs seems to be a bit of a bloat but I have no strong objections.

In context of server using two ACL relations (rel=acl, rel=acl:inheritedACL) with fixed URLs (as per resource lifecycle and hierarchical containment), updates are a non-issue. It becomes an issue if the target of the link relation is not persistent, and where clients need to associate an ACL to a resource. While that's currently not possible, it can be worked out by adopting LINK and UNLINK methods.

[csarven]

No. At least I was using "effective ACL" as equivalent to '"ACL currently in effect" (which might be the inherited one)?'

HEAD /resource

200
Link rel=acl /resource.acl

/resource.acl is always the specific ACL for /resource .

If HEAD /resource.acl returns 200, it is the effective ACL.

If HEAD /resource.acl returns 404, and client finds /.acl, that'd be the effective - the inherited - ACL.

[csarven]

servers MUST only return the effective ACL

didn't distinguish between specific and inherited. It is literally the only effective ACL using rel=acl. It is "specific" within the context of what's effective. If server determined that /resource.acl exists, that'd be the effective and so it would return that in Link of /resource. If /resource.acl didn't exist, and the server determined that /.acl is inherited (and so effective), then it would only return /.acl in Link of /resource

That approach is different than rel=acl strictly being used for resource specific ACL ie. having only /resource.acl target (but never /.acl as you've said above). Links of /resource would be rel=acl /resource.acl and rel=inheritedacl /.acl (if /resource.acl didn't exist).

Does that clarify:

What's on the table:

• Clients use the inheritance algorithm to discover a resource's inherited ACL.
• Servers advertise a resource's inherited ACL independently of its specific ACL.

[csarven]

I want to create an ACL specifically for /foo/bar/resource, but I don't know where to PUT it. I can't rely on the .acl convention.

PUT is not an issue in and itself because of:

As mentioned, shared slash semantics and hierarchical paths limit the possibilities eg. "/foo/bar 's ACL can be /foo/bar.acl , /foo/.acl , /.acl , but not /baz/qux.acl or /baz/.acl."

So, yes, you can create /foo/bar/resource.acl (or whatever naming) as long as the hierarchy holds. What's not possible is actually:

associating an ACL with a resource

because we don't have a way to connect / update the relation with the new ACL that's created. It can be remedied with

by adopting LINK and UNLINK methods

if that direction is so desired.

".acl" convention is not part of the spec.