subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <comm...@subversion.apache.org>
Subject [Subversion Wiki] Update of "AuthzImprovements" by StefanFuhrmann
Date Sat, 30 Aug 2014 18:41:19 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.

The "AuthzImprovements" page has been changed by StefanFuhrmann:
https://wiki.apache.org/subversion/AuthzImprovements?action=diff&rev1=4&rev2=5

Comment:
Update to current implementation and address Brane's points

   Affected operations are mainly checkout / export and log.
  
   * Support for wildcards. Subversion should support
-   * "*" or single, arbitrary path segments (with no "/" in them) and
+   * "*" for single (exactly one), arbitrary path segments (with no "/" in them) and
-   * "**" for arbitrary length non-empty paths.
+   * "**" for arbitrary number (zero to infinite) of path segments.
-   * Classic wildcard patterns like "*foo*.bar" shall be supported.
+   * Classic wildcard patterns like "*foo*.bar", including escapement via the "\" prefix
shall be supported.
+   The asterisks in there match zero to many characters other than "/" making the whole segment
form "/*/"
+   a mere special case of this.
   All wildcard usage applies to full path segments only, i.e. a '*'
   never matches a '/' except for the case of "/**/" where it matches
-  one to many full segments.
+  zero to many full segments. For example, "/*/**/*" will match any path that contains at
least 2 segments
+  and is equivalent to "/**/*/*" as well as "/*/*/**".
  
  {{{#!wiki caution
  '''Missing definitions:'''
@@ -35, +38 @@

  Whildcards are valid segments and their interpretation depends
  on the context.
  
- A '''rule set''' contains a number of '''rules''', each
+ A '''access control list (ACL)''' contains a number of '''access control elements (ACE)''',
- describing what '''users''' shall have which '''access rights'''.
+ each describing what '''users''' shall have which '''access rights'''. Users might be specified
- Users might be specified indirectly by using '''groups'''.
+ indirectly by using '''groups'''.
  
- A '''path rule''' specifies what rule set applies to a given path.
+ A '''path rule''' specifies what ACL applies to a given path.
  
  
  == Inheritance and disambiguation ==
  
  These are the rules as of today, with rule 3 added to support
- ambiguous path patches caused by pattern matching.
+ ambiguous path patches caused by pattern matching.  Please note
+ the difference between ''matching'' (does a path fully match a
+ given pattern?) and ''applying to'' (governing the access rights).
  
-  1. Path rules implicitly apply to all paths in the respective
-  sub-tree.
+  1. An ACL is relevant to a user if the user, one of aliases or
+  groups that they are a member of is mentioned by at least one
+  ACE in that ACL.
  
+  2. Only path rules with ACLs relevant to the given user may
+  match a path.
+ 
+  3. If a path rule matches a given repository path, its ACL applies
+  to that path.
+ 
+  4. If no path rule matches a given repository path, the parent
+  path's ACL applies.
+ 
+  5. If no ACL is given for the repository root, a default ACL
+  denying access to anybody applies to the root path.
+ 
-  2. If multiple path rules match a given repository path, only
+  6. If multiple path rules match a given repository path, only
-  the path rule(s) that cover the most segments shall apply.
- 
-  3. If multiple path rules cover the same number of segments,
-  only the one specified last in the authz file shall apply.
+  the one specified last in the authz file shall apply.
  
+  7. If multiple ACEs of a given ACL apply to a user, the sum of
+  all individually granted access rights is granted.
-  4. If there are multiple rules in a rule set for a given
-  user, the union of all rights granted shall apply.
- 
-  5. The following rule is implicitly added as the first rule
-  given no access to anybody by default.
- {{{
- [/]
- * =
- }}}
  
  
  == Design ==
@@ -85, +93 @@

  Putting caching aside, the workflow involved three data models,
  building on top of each other.
  
-  * Parsing an authz file (from file system or repository)
+  * Parsing an authz file (from file system or repository),
-  yields a consolidated hash (additive sections being combined
-  automatically) of it contents in svn_config_t.
+  validating its contents and creating a pre-processed in-memory
+  representation.  In comparison to the old svn_config_t
+  based code, additional restrictions apply:
+   * No rule may appear more than once in the authz file.
+   * Value placeholders (`%(name)s`) are not expanded.
  
  {{{#!wiki caution 
  This is the current behaviour of the authz files, but only because we happen to use an `svn_config_t`
to represent a parsed authz files. I suggest we should constrain the semantics for authz rules:
@@ -102, +113 @@

    * prefix tree with one node per segment
    * created on demand per user and repository
    * contains only rules that apply to the respective user and repository
-   * multiple instances of that being cached in the svn_authz_t structure alongside the single
svn_config_t
+   * multiple instances of that being cached in the svn_authz_t structure alongside the single
"full model"
-   * rule sets being reduced to access rights + order ID
+   * ACLs being reduced to access rights + order ID
    * each node knows min / max rights on all sub-nodes
  
   * Lookup state
@@ -131, +142 @@

  filtered-node :=
  	segment   : string		// empty for root
  	access    : ref to access-type	// empty if no path ends here
- 	min-rights: none | r | w | rw	// user's minimum rights on any path in the sub-tree
+ 	min-rights: none | r | rw	// user's minimum rights on any path in the sub-tree
- 	max-rights: none | r | w | rw	// user's maximum rights on any path in the sub-tree
+ 	max-rights: none | r | rw	// user's maximum rights on any path in the sub-tree
  	repeat    : boolean		// set on nodes for "**" segments
  
  	sub-nodes : { map following segment => filtered-node }[0..*]
@@ -153, +164 @@

  
  access-type :=
  	order-id  : integer		// increases with declaration order in the file
- 	rights    : none | r | w | rw
+ 	rights    : none | r | rw
  }}}
  
  {{{#!wiki caution
@@ -167, +178 @@

  {{{
  lookup-state :=
  	access    : ref to access-type	// user's rights for this path
- 	min-rights: none | r | w | rw	// user's minimum rights on any path in the sub-tree
+ 	min-rights: none | r | rw	// user's minimum rights on any path in the sub-tree
  					// (aggregated over RIGHTS and all nodes in CURRENT)
- 	max-rights: none | r | w | rw	// user's maximum rights on any path in the sub-tree
+ 	max-rights: none | r | rw	// user's maximum rights on any path in the sub-tree
  					// (aggregated over RIGHTS and all nodes in CURRENT)
  	current   : { ref to filtered-node }[0..*]
  					// sub nodes of these may match the next segment
@@ -185, +196 @@

  
  — Brane}}}
  
- Wildcard sequences in paths in rule sets shall be normalized.
+ Wildcard sequences in paths shall be normalized internally.
- This is merely done to reduce matching costs later on.
+ This is merely done to reduce matching costs later on and some of
+ the matching code may rely on normalizes pattern.
  {{{
- 	// Variable length wildcards must be the last in a sequence
+ 	// Variable length wildcards shall be the last in a sequence
  	while path contains "/**/*/"
  		replace occurrence with "/*/**/"
  
  	// Consecutive variable length wildcards are redundant
  	while path contains "/**/**/"
- 		replace occurrence with "/*/**/"
+ 		replace occurrence with "/**/"
- 
- 	// Trailing variable length wildcards are redundant
- 	if path ends with "/**"
- 		replace occurrence with "/*"
- 
- 	// "**" within segment patterns are redundant
- 	while path contains "**" not immediately preceded by "/"
- 		replace occurrence with "*"
- 	while path contains "**" not immediately followed by "/"
- 		replace occurrence with "*"
  }}}
  === Lookup ===
  

Mime
View raw message