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 ===
