[FEATURE]: extend authz algorithm with roles and wildcards to define branch policies.

Hi devs,

as a result of the thread on the users list, and a discussion I had tonight
on #svn-dev, I want to propose implementation of two new features.
( users list thread:
http://svn.haxx.se/users/archive-2005-12/index.shtml#988 )

Summary:
--------
Allow to assign read/write access in the authz algorithm for roles instead
of groups, and on branch types instead of specific branches.
Two changes ( extensions ) in the authz algorithm are needed:
- add the concept of a role, and allow access rights to be given to a role
instead of a group
- allow wildcard matching to match branch types instead of actual branches
      
Use case:
---------
I'm part of a team managing up to 100 repositories in a coorporate
environment.
Setup of a repository is managed by strict policies, which are identical for
each of the 100 repositories. Based on their experience and focus people are
given a certain role to fullfil in the team as related to the svn
repository.
Examples of roles: developers, release coordinators, bugfixers...

We allow six different types of branches, each with their own specific
policy and marked with a certain prefix.
Examples of branch types: development(DEV_*), maintenance(MAINT_*),
hotfix(HF_*)...

While roles and branch types are generic for all the repositories, each
repository has its own group of developers, release coordinators etc.

Changes:

Change 1: implement wildcards
-----------------------------
To match not only on a specific branch, but allow matching on branch types,
the use of wildcards is needed:
[groups]
dev = account1, account2

[:/branches/DEV_*]
dev = rw
[:/branches/MAINT_*]
relco = rw

Change 2: add the role concept in the authz algorithm ( and only there! )
-------------------------------------------------------------------------
Current groups are actually a combination of repository + roles. Currently,
we define groups as such:
[groups]
repo1_dev = account1, account2
repo2_dev = account3, account4
admin = account5

The change is twofold:
1) define a separator ( eg. '.' ) which allows a true distinction between
repo and role:
[groups]
repo1.dev = account1, account2 # -> separate repository and role with
'.'
repo2.dev = account3, account4
admin = account5

2) allow the use of the role relative to the repository as a way to describe
access rights:
[:/branches/DEV_*]
.dev = rw # -> repo1.dev has rw access on
repo1:/branches/DEV_V0001.01.00
                  # repo2.dev has rw access on
repo2:/branches/DEV_V0002.00.00
@admin = rw

Implementation details
----------------------
Some implementation details/issues were discussed on irc ( mainly with
danderson, also darix ):
Concerning wildcard matching:
- If we just at wildcard matching in the authz algorithm, performance will
suffer, even for users not using wildcards at all.
  While wildcard matching is normally only done after first evaluation the
specific cases, the "no match at all" case is still slowed down.
  A possible solution suggested by David is to scan all sections when the
file is opened, searching for glob patterns and if there are none, just do
simple matching. Otherwise, a double iteration might be feasible.
- The new syntax has to be supported by Python's ConfigParser module.
- Suggestion was made by darix to directly implement full RegEx features.
This has direct impact on syntax and creates an extra dependency on the
apache regex parser.

Concerning roles:
- while syntax for role definition ( the '.' separator and '.role' for role
matching )
  seems ok, this has to be double checked: is it clear enough?
- backwards compatibility is mandatory, and I think it's handled by this
proposal. Is
  it currently allowed to start a group's name with a '.' ?

I hope this text explains it clearly enough?

Thanks for your comments, a little discussion to finish the design is very
much appreciated!

regards,

Lieven.

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.7/214 - Release Date: 23/12/2005
 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org