David,
thank you for the clear remarks on this topic.
Based on this remarks, I put some more thought into the definition of
my requirements. For me it's not really important how it is implemented,
the only thing that's important is that what's implemented handles my
requirements.
> Also, once a complete proposal is put together, please send it to the
> development mailing list. Subversion developers aren't necessarily
> subscribed to the users list, as it is quite high trafic. I'm one still
> subscribed, and am rather interested. I built authz support into
> svnserve for 1.3.0, and have a few plans to expand authz somewhat. If
> this proposal is feasible (warning - there are problems), then it could
> be one of the things added.
Let's hope so; I suppose the best way is to discuss and fix requirements, and
with your assistance draft an implementation proposal.
> > No seriously. The use regular expressions in the authz_svn module has
> > been discussed on the dev list before, there's even been a patch
> > submitted to that list:
> > http://svn.haxx.se/dev/archive-2005-02/0631.shtml It wasn't accepted
> > though, and the author seems to have given up on it.
>
Besides your valid remarks concerning this patch, I read also that there's an
official Python library as well that parses the access file, so whenever change
is made in the syntax of the file, this library has to be updated as well.
> In that mail, you suggest regular expression matching, which I'll return
> to a little later, but also LDAP group integration. In the light of my
> previous statement, understand that this is not even contemplatable.
> Adding an LDAP dependency in a subversion core library is out of the
> question.
>
Forget LDAP for now, the proposal we make for reg.ex. should be standalone.
> > We have two use cases for regular expressions: 1. wildcard matching
> > of paths, to allow groups automatic write access on all branches of
> > the same type.
>
> This is wildcard support on paths, and has already been considered and
> discussed. I can't remember if there were any obstacles to
> implementation, but note that apr_fnmatch exists and seems to provide
> shell-style wildcard matching, and could be used for this.
>
> > 2. capturing groups: reuse the name of the repository as prefix for
> > the group name, so not all 50 repositories have to be configured
> > individually.
>
> This is much more complex, and requires a fully fledged PCRE engine to
> perform. This means either adding another dependency to the Subversion
> core code, to support PCRE, or make this specific to apache as described
> above. I think that the latter is not really acceptable either, as PCRE
> support would be a fundamental change to the authz code, and should be
> shared across servers.
>
> As I said before, I am certainly not opposing this proposal, as the uses
> do exist and are cool. I am merely pointing out the new constraints
> that 1.3 code will bring to such changes, so that a proposal has better
> chances of being well received.
>
> > What are your or other peoples requirements? Would be nice to finish
>
> > a complete proposal here.
>
> Well, my requirement is to avoid, to any extent possible, the
> introduction of extra dependencies on external systems, and to consider
> any changes along with their impact, now that authz is core svn code.
> There are enough people complaining about the number of dependencies in
> Subversion without adding more :-).
>
> Also, a note on performance issues: avoid anything that would require
> systematically sieving large chunks of the authz configuration to be
> applicable. The current code is nice, in the sense that in many cases
> it can "bail early", having gotten sufficient information to make a
> decision without jumping through 90% of a 15k authz file. Don't worry
> too hard about it at this stage, we can get back to performance issues
> once a conceptual proposal is fleshed out, but keep it in mind if
> anything that is clearly cpu hungry comes up.
> If a consensus is reached with a proposal, I'd be willing to implement
> it.
>
> Regards,
> - Dave
Good points, technical issues like these will probably make design approval
and implementation a long process.
Let me rephrase my requirements and suggest an alternative solution.
My goal is plain and simple: allow easier (ie. automated) administration of
users and access rights on branches.
My requirements:
- implement roles:
In my scenario all repository users fit one or more roles, ie. developers,
bugfixers, release coordinators etc. Roles are not specific for a certain
repository ( they're part of the standard and procedures ), but each
repository has it's own list of users fitting certain roles.
Implementation of roles is now done by defining groups.
- implement branch policies:
We have different policies for types of branches. While a branch policy
contains multiple rules, like the type of code changes, how to commit etc. the
only rule I need to implement here is how to limit write access to certain
roles only.
- generic configuration <-> repository specific overrides
I need two options of configuration:
1. For all repositories, give write access on this type of branch to that
role.
ex. give all developers write access to DEV_ branches, but only in the
context of the repository they have access to.
2. For a certain repository, override the standard role-based write access
ex. for repository 'test' only, give write access to everyone on all
branches.
Proposed solution:
1. The first part of the solution is wildcard matching. We already discussed
that and from requirement point-of-view this is clear.
2. The second part is the conceptual matching of roles on groups.
A group as used in the access file can be used to define roles, but only
specific to a certain repository.
I see the definition of a group as: group = repository + role.
An implementation of this concept needs:
- definition of groups as repository + role
- matching on roles for write access policy definition.
A example could be:
[groups]
a001.dev = account1, account2 # -> separate repository and role with '.'
[*:/branches/DEV_(.*)]
.dev = rw # -> indicate role relative to repo with '.'
Benefit of this solution is that it's simple to document and explain, while
still maintaining backwards compatibility. And, we do not need PRCE!
If we could make this distinction in the access file than my requirements
are matched.
regards,
Lieven.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Dec 25 01:35:35 2005