From 0d63850889feaa4dc8af9059cd79e6ac8f0b80e8 Mon Sep 17 00:00:00 2001 From: Henry Story Date: Mon, 1 Feb 2016 11:26:38 +0000 Subject: [PATCH 1/3] proposal for wac:defaultInclude relation for acl. --- acl-inheritance.md | 56 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 52 insertions(+), 4 deletions(-) diff --git a/acl-inheritance.md b/acl-inheritance.md index 27b2841..b200a03 100644 --- a/acl-inheritance.md +++ b/acl-inheritance.md @@ -21,14 +21,14 @@ In `monotonic`, ACL permissions are cumulative (inherited from the ancestors) an #### Pro - Not as fast as defaultForNew but can be -- Simple hierarchical permission (e.g. everything in `/shared` is shared) +- Simple hierarchical permission (e.g. everything in `/shared` is shared) (bblfish: does that mean that a resource cannot unlink from a previous permission?) - Can be fast as it only has to find one ACL file to give the permission it needs - Monotonic: Once a user or any agent knows the ACL it can apply it as a rule. An ACL is a first class fact. It can be digitally signed, transported, and used to demand access at a later date, etc. Monotonicness is useful. #### Cons - It is slower than `defaultFor new`, but the search stops the moment it finds success. - It can't have private subfolders within shared folders. Given that permissions cannot be reverted (with the current WAC specification), a subfolder cannot be private in a shared folder. This system is monotonic. -- User has to be aware of the permissions given to the parent folders +- User has to be aware of the permissions given to the parent folders (bblfish: why not use `wac:include`?) ((A possible solution is NOT include Windows' `DENY` or `DENY all` in the WAC specification, where these entries would take precedence to the other (_allow_) permissions) That would not be monotonic. @@ -45,15 +45,63 @@ In `defaultLocal`, ACL permissions are inherited from the most local ACL file wh ### Strategy 3) `defaultForNew` -In `defaultForNew`, ACL permissions are inherited from the whole path as in 'momotonic', but done from the end of the path top the root. With this method, however, whenever a file dopes not have a local ACL, one is generated for it, so that in future the search will hit it immediately. +In `defaultForNew`, ACL permissions are inherited from the whole path as in 'monotonic', but done from the end of the path top the root. With this method, however, whenever a file does not have a local ACL, one is generated for it, so that in future the search will hit it immediately. #### Pro - Fast #### Cons -- Generates a storage reuirement for all the ACL files, which is a pain, especialy in a fiel space shared with other systems. +- Generates a storage requirement for all the ACL files, which is a pain, especialy in a fiel space shared with other systems. - Users may lose access to their resource by creating an ACL file that does not contain themselves. - Changing permissions recursively to a folder will require changing permission on each subfolder's ACL + + +### Strategy 4) resource centric + +Note by bblfish: this may be related to the previous points but I can't tell for sure, as there are a lot of words that are not defined clearly enough for me. Also see wiki page [regexes in ACLs](https://github.com/solid/solid/wiki/Regexes-in-ACLs) + +[rww-play](https://github.com/read-write-web/rww-play) takes a resource centric view of acls. Any resource ``'s acl link relation (given by the http header `Link: ; rel="acl"`) specifies the acl starting point for that resource. This must be the case as that is the only way a client can find out about an acl for a resource. The client and the server must therefore start from that acl and follow any [wac:include](http://www.w3.org/ns/auth/acl#include) relations which should be logically mergeable monotonically to create the complete acl for that resource. Given that these mergers happen monotonically the server can stop at any moment it finds an acl that gives the user permission, in the knowledge that any other acl included cannot undo the statement added. +Note: if it can be shown that ACLs can be inconsistent, then a SoLiD server may want to check the consistency of these acls before allowing a write to succeed. + +Given the above, here is one way for a container to deal with defaults for new resources that works by reference using a +relation `wac:defaultInclude` that points from an acl file to another one that will be included by default in any new resource created. + +This would work like this. Consider an `ldp:Container` named ``'s whose acl file `` includes the statement + +```Turtle +<.> wac:defaultInclude . +``` + +On creation of a new resource eg, by `POST`ing some content to `` with Slug "cat", thereby creating a new resource `` and the associated `` the server on finding the above wac:defaultInclude statement in the container's acl will add the statement: + +``` +<> wac:include . +``` + +in the created resource's acl. + +#### Pro + * If somone wants to change the all the resources that have a certain default, they can do so just by changing ``. + * If someone wants a particular resource to not have the defaults, they can just remove the `wac:include` triple. + * Reduces storage requirements + * Is very maintainable + * Is monotonic + * client and server verification mechanisms follow the same discovery process + +#### Cons + * verifying an ACL will often require fetching one new default acl, but that is local so it should be very fast. + * this does require some form of regular expression (e.g. a simple version based on globbing such as `"/*.acl"`) as the `wac:include`ed `default.acl` needs to make statements about sets of resources such as +```Turtle + [] acl:accessToClass [ acl:regex "https://jack.example/.*[.]acl" ]; + acl:mode acl:Read; + acl:agentClass foaf:Agent . +``` + +#### Issue + +It does mean that on a naive reading of `wac:regex` some acls will not actually be true of all files specified in the regular expression, as they are only valid if the resource's acl includes them using `wac:include`. Perhaps there is a way of thinking of the `acl:regex` relation in way that does not create such false statements. Perhaps it should be read as defining the subclass of resources that fit the given pattern _and_ that whose acls are linked to via a set of `wac:include`s to the resource that contains the regular expression. On this reading one cannot deduce that `https://jack.example/cat.acl` is readable by everyone only from the acl shown in the cons section above. One also needs to know: + * that `` exists + * that `` has an `acl` link header to a resource that through a chain of `wac:include`s refers back to `` -- From b5c384517a73195e7c3793d028487a47769a1547 Mon Sep 17 00:00:00 2001 From: Henry Story Date: Mon, 1 Feb 2016 13:05:04 +0000 Subject: [PATCH 2/3] initial proposal 4 simpler and better pattern language --- acl-inheritance.md | 38 +++++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-) diff --git a/acl-inheritance.md b/acl-inheritance.md index b200a03..6cb0db3 100644 --- a/acl-inheritance.md +++ b/acl-inheritance.md @@ -97,12 +97,48 @@ in the created resource's acl. acl:agentClass foaf:Agent . ``` -#### Issue +#### Issues + +##### Truth It does mean that on a naive reading of `wac:regex` some acls will not actually be true of all files specified in the regular expression, as they are only valid if the resource's acl includes them using `wac:include`. Perhaps there is a way of thinking of the `acl:regex` relation in way that does not create such false statements. Perhaps it should be read as defining the subclass of resources that fit the given pattern _and_ that whose acls are linked to via a set of `wac:include`s to the resource that contains the regular expression. On this reading one cannot deduce that `https://jack.example/cat.acl` is readable by everyone only from the acl shown in the cons section above. One also needs to know: * that `` exists * that `` has an `acl` link header to a resource that through a chain of `wac:include`s refers back to `` +#### Better Pattern Languages + +The problems with full regexes are: + +* one needs to know the full url of the resource +* different languages have different implementations of regexes +* they can be turing complete + +This should not stop one. Regexes are already standardised by the W3C in RDF via the [POWDER spec](https://www.w3.org/TR/powder-dr/), which also provided simpler less powerful vocabularies to enable use cases that did not require the full regex power. So one could invent a simple regular expression based on globbing such as `"/*"` for all resources in a folder, or `"/**"` for all resources in a folder and sub-folders. This could look like the following: + +```Turtle +[] acl:accessToClass [ acl:urlPattern [ acl:base <.>; acl:match "*.acl" ]]; + acl:mode acl:Read; + acl:agentClass foaf:Agent . +``` + +This should be read as saying that everybody can read all resources that match the pattern "*.acl" in the current directory, and for which this is an acl through wac:include chain from the resource's acl. (in this case this is a rule on acls) + +To allow all files to be readable and writeable by the owner in this folder and sub-folders one could use + +```Turtle +[] acl:accessToClass [ acl:urlPattern [ acl:base <.>; acl:match "**" ]]; + acl:mode acl:Read, acl:Write; + acl:agent . +``` + +assuming of course the user's WebID is `` . +Note again that the `acl:urlPattern` gives a class that is larger than the class of resources for which this is true, as the only resources for which that rule is valid are those whose acls link to the acl in which this is written. + + + +The advantage of such a pattern language is that it allows the pattern to be relative to a resource, and so to be written out even for a client that does not know the full url of the resource. + + -- ## References From 0cd662add22a7a6cc515a5fad1d39d22a2500e84 Mon Sep 17 00:00:00 2001 From: Henry Story Date: Mon, 1 Feb 2016 18:25:18 +0000 Subject: [PATCH 3/3] remove comments --- acl-inheritance.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/acl-inheritance.md b/acl-inheritance.md index 6cb0db3..bcb2801 100644 --- a/acl-inheritance.md +++ b/acl-inheritance.md @@ -21,14 +21,14 @@ In `monotonic`, ACL permissions are cumulative (inherited from the ancestors) an #### Pro - Not as fast as defaultForNew but can be -- Simple hierarchical permission (e.g. everything in `/shared` is shared) (bblfish: does that mean that a resource cannot unlink from a previous permission?) +- Simple hierarchical permission (e.g. everything in `/shared` is shared) - Can be fast as it only has to find one ACL file to give the permission it needs - Monotonic: Once a user or any agent knows the ACL it can apply it as a rule. An ACL is a first class fact. It can be digitally signed, transported, and used to demand access at a later date, etc. Monotonicness is useful. #### Cons - It is slower than `defaultFor new`, but the search stops the moment it finds success. - It can't have private subfolders within shared folders. Given that permissions cannot be reverted (with the current WAC specification), a subfolder cannot be private in a shared folder. This system is monotonic. -- User has to be aware of the permissions given to the parent folders (bblfish: why not use `wac:include`?) +- User has to be aware of the permissions given to the parent folders ((A possible solution is NOT include Windows' `DENY` or `DENY all` in the WAC specification, where these entries would take precedence to the other (_allow_) permissions) That would not be monotonic. @@ -58,7 +58,7 @@ In `defaultForNew`, ACL permissions are inherited from the whole path as in 'mon ### Strategy 4) resource centric -Note by bblfish: this may be related to the previous points but I can't tell for sure, as there are a lot of words that are not defined clearly enough for me. Also see wiki page [regexes in ACLs](https://github.com/solid/solid/wiki/Regexes-in-ACLs) +Also see wiki page [regexes in ACLs](https://github.com/solid/solid/wiki/Regexes-in-ACLs). [rww-play](https://github.com/read-write-web/rww-play) takes a resource centric view of acls. Any resource ``'s acl link relation (given by the http header `Link: ; rel="acl"`) specifies the acl starting point for that resource. This must be the case as that is the only way a client can find out about an acl for a resource. The client and the server must therefore start from that acl and follow any [wac:include](http://www.w3.org/ns/auth/acl#include) relations which should be logically mergeable monotonically to create the complete acl for that resource. Given that these mergers happen monotonically the server can stop at any moment it finds an acl that gives the user permission, in the knowledge that any other acl included cannot undo the statement added. Note: if it can be shown that ACLs can be inconsistent, then a SoLiD server may want to check the consistency of these acls before allowing a write to succeed.