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

Precise definition of acl:default #63

Closed
Otto-AA opened this issue Jul 11, 2019 · 16 comments
Closed

Precise definition of acl:default #63

Otto-AA opened this issue Jul 11, 2019 · 16 comments

Comments

@Otto-AA
Copy link

Otto-AA commented Jul 11, 2019

The spec states "[...] if an Authorization contains acl:default, it will be applied by default to any resource in that container". Does that mean that value after acl:default doesn't make any difference?

For instance should following statements be treated as equivalent?

<#1> acl:default <https://alice.databox.me/docs/>
<#1> acl:default <https://alice.databox.me/foo/bar/>
@michielbdejong
Copy link
Contributor

michielbdejong commented Sep 17, 2019

No, that's not how acl:default works. There are two situations when looking for the applicable ACL doc: the resource has its own ACL doc (a Link response header points to a resource that exists), or it defaults to its nearest parent (the resource's Link response header leads to a 404).

In the first case, look for acl:accessTo, in the second case, look for acl:default instead.

acl:defaultForNew is treated as a deprecated synonym for acl:default.

@Otto-AA
Copy link
Author

Otto-AA commented Sep 19, 2019

Thanks for coming back to this question. I think I am understanding what you are saying, but I'm not sure how it answers my question.

I'll try to explain my question with a simple example. Here is the example for acl:default from the wac-spec. Only the last line is changed:

# Contents of https://alice.databox.me/docs/.acl
@prefix  acl:  <http://www.w3.org/ns/auth/acl#>.

<#authorization1>
    a                  acl:Authorization;

    # These statements specify access rules for the /docs/ container itself:
    acl:agent          <https://alice.databox.me/profile/card#me>;
    acl:accessTo       <https://alice.databox.me/docs/>;
    acl:mode           acl:Read, 
                       acl:Write, 
                       acl:Control;

    # default says: this authorization (the statements above) 
    #   will also be inherited by any resource within that container 
    #   that doesn't have its own ACL.
    acl:default  <https://alice.databox.me/docs/first.ttl>.

I've changed the value of acl:default from ".../docs" to ".../docs/first.ttl". Does this change the behavior of it? Or is this value redundant?

@acoburn
Copy link
Member

acoburn commented Sep 19, 2019

@Otto-AA asks an excellent question here. I have had that same question, myself.

I also have another question that touches on acl:default, building on the example above:

Assume there exist the following four resources:

  • https://alice.databox.me/docs/
  • https://alice.databox.me/docs/photos/
  • https://alice.databox.me/docs/photos/spain/
  • https://alice.databox.me/docs/photos/spain/1.jpg

The /docs/.acl ACL is similar to what is above except that acl:default points to https://alice.databox.me/docs/

There is also a /docs/photos/.acl resource without an acl:default value and which only grants acl:Read access:

# Contents of https://alice.databox.me/docs/photos/.acl
@prefix  acl:  <http://www.w3.org/ns/auth/acl#>.

<#authorization1>
    a                  acl:Authorization;
    acl:agent          <https://alice.databox.me/profile/card#me>;
    acl:accessTo       <https://alice.databox.me/docs/photos/>;
    acl:mode           acl:Read .

There is no ACL resource for https://alice.databox.me/docs/photos/spain/ or for https://alice.databox.me/docs/photos/spain/1.jpg.

If the user https://alice.databox.me/profile/card#me wishes to DELETE /docs/photos/spain/1.jpg, will that be allowed? (via inheriting from the ACL at /docs/.acl) or will that be rejected (via inheriting from the ACL at /docs/photos/.acl)?

@Otto-AA
Copy link
Author

Otto-AA commented Sep 19, 2019

@acoburn I believe it would use /docs/.acl in your case because this is the first acl file with acl:default specified, hence providing the first permissions which can be inherited.

From the ACL Inheritance Algorithm:

  1. Failing that, move up the container hierarchy until you find a container with an existing ACL file, which has some permissions to inherit

@acoburn
Copy link
Member

acoburn commented Sep 19, 2019

@Otto-AA yes, that is also my understanding (and that is how I have implemented the WAC algorithm myself), but it is worth noting that the definition in the algorithm conflicts in this regard with what is stated in the ACL namespace:

If a resource has no ACL file (it is 404), then access to the resource if given by the ACL of the immediately containing directory, or failing that (404) the ACL of the recursively next containing directory which has an ACL file. Within that ACL file, any Authentication which has that directory as its acl:default applies to the resource. (The highest directory must have an ACL file.)

That is, when looking up the containment hierarchy, does one stop at the first "container with an existing ACL file [with] permissions to inherit" (as per the algorithm described here) or at the first container resource "which has an ACL file" (as per the vocabulary).

@michielbdejong
Copy link
Contributor

@Otto-AA

I've changed the value of acl:default from ".../docs" to ".../docs/first.ttl". Does this change the behavior of it? Or is this value redundant?

Here you're mixing up the target URL of the request and the context URL of the ACL doc.
Remember we're consulting https://alice.databox.me/docs/.acl to learn ACL rules about https://alice.databox.me/docs/ and so any rule that's not about https://alice.databox.me/docs/ will be ignored.

So you should always keep track of three resources, and not confuse them:

  • targetUrl, the resource being accessed (in this case https://alice.databox.me/docs/first.ttl)
  • contextUrl, the closest parent resource for which an ACL doc exists (in this case https://alice.databox.me/docs/)
  • aclDocUrl, that ACL doc (in this case https://alice.databox.me/docs/.acl)

All acl:default and acl:accessTo triples should have an authorization (aclDocUrl + #something) as their subject and the contextUrl as their object.

@acoburn

If the user https://alice.databox.me/profile/card#me wishes to DELETE /docs/photos/spain/1.jpg, will that be allowed? (via inheriting from the ACL at /docs/.acl) or will that be rejected (via inheriting from the ACL at /docs/photos/.acl)?

that will be rejected. Only one ACL doc, the closest one up the tree, is looked at - in this case /docs/photos/.acl and not /docs/.acl

@acoburn
Copy link
Member

acoburn commented Sep 20, 2019

If the user https://alice.databox.me/profile/card#me wishes to DELETE /docs/photos/spain/1.jpg, will that be allowed? (via inheriting from the ACL at /docs/.acl) or will that be rejected (via inheriting from the ACL at /docs/photos/.acl)?

that will be rejected. Only one ACL doc, the closest one up the tree, is looked at - in this case /docs/photos/.acl and not /docs/.acl

In that case, what is the use of acl:default?

@acoburn
Copy link
Member

acoburn commented Sep 20, 2019

@michielbdejong in the ACL Inheritance Algorithm Example, it appears clear that acl:Authorization statements are inherited only if they contain acl:default. See, in particular, step 2 and 3.

@michielbdejong
Copy link
Contributor

michielbdejong commented Sep 23, 2019

I think acl:accessTo / acl:default is a misnomer and better names would have been
acl:accessToResourceItself / acl:accessToDescendantResources.

That's how you interpret the ACL doc once you've found it. The word inheritance is confusing there, and so is the word default.

And then to find the ACL doc that applies, you just walk up the tree and stop when you find one. So there inheritance is also confusing, because in biology you inherit things from all your ancestors up to the root, and in WAC you don't.

EDIT: Sorry, I wrote acl:accessToDirectlyContainedResources but that should be acl:accessToDescendantResources, so directly contained + sub-container contained, etc.

@Otto-AA
Copy link
Author

Otto-AA commented Sep 23, 2019

I agree with @acoburn that the current form of the WAC-spec clearly states, that it looks for the next parent with an acl:default expression. I personally don't see how I could interpret it the way you do, @michielbdejong .

From the example in the spec:

  1. If the document's container has no ACL resource of its own, the search continues upstream, in the parent container. The server would check if /documents/.acl exists, and then /.acl, until it finds some authorizations that contain acl:default.

@Otto-AA
Copy link
Author

Otto-AA commented Sep 23, 2019

@michielbdejong

All acl:default and acl:accessTo triples should have an authorization (aclDocUrl + #something) as their subject and the contextUrl as their object.

Is this specified somewhere? As far as I've seen, the specification doesn't mention what the object of acl:default should be.

@michielbdejong
Copy link
Contributor

@Otto-AA you're right, the only phrase that describes not looking at the presence of acl:default statements is "If the document's container has no ACL resource of its own, the search continues upstream". My reason for creating #70 is that it's how the current servers work in practice, so the 0.8 spec should be corrected to describe that. We can then have a discussion in solid/specification#55 about whether the current Solid server deployments should switch to the different behaviour that is described in the current spec text, or maybe even to yet other behaviour.

@acoburn
Copy link
Member

acoburn commented Sep 23, 2019

My reason for creating #70 is that it's how the current servers work in practice, so the 0.8 spec should be corrected to describe that.

This is not correct. There are implementations in the wild right now that follow the algorithm as described in the specification text. It does not follow that the specification text should be changed because one particular implementation does not follow those rules. (And I think it should be verified that, in fact, NSS does not conform, because these lines suggest that it does).

@timbl
Copy link

timbl commented Sep 27, 2019

All the code I have ever written follows the spec.
Does the value of acl:default matter? Yes.

Is "default" too short when it should be something lke "defaultForThingsWhich DoNotHaveACloserACLFileAndAreBelowThis" ? maybe a bit .. Make contentsDefault or something... but it is definitely a default, as it provides a fallback ACL for anything until that thing has something of its own or something closer.

@timbl timbl closed this as completed Sep 27, 2019
@RubenVerborgh RubenVerborgh changed the title Does the value of acl:default matter? Precise definition of acl:default Sep 28, 2019
@RubenVerborgh
Copy link
Contributor

RubenVerborgh commented Sep 28, 2019

While @timbl's answer settles the question of whether it matters, I'd still like to see a precise definition of how it matters. It seemed meaningful to repurpose this issue in that sense.

Specifically, I'd like a definition of the set of resources affected by the default.

Also, @acoburn's question was specifically about the value (triple object) of the triple. How does it affect behavior? What kind of values are allowed in a given folder? Should they always be subfolders of the current folder? Etc.

@RubenVerborgh RubenVerborgh reopened this Sep 28, 2019
@RubenVerborgh
Copy link
Contributor

Ah wait, this is just a duplicate of solid/specification#55 then. Let's continue over there.

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

5 participants