[Restored CC of the mailing list]
On Thursday, October 17, 2013 03:24:45 PM Mark Phippard wrote:
On Thu, Oct 17, 2013 at 3:00 PM, Alexey Neyman <stilor_at_att.net[1]> wrote:
We are actively using authz path-based authentication rules: due to some
legalrequirements, some parts of our product source code are not accessible to
apart of the developer team. Currently authz does not support wildcards (thereis
an issue about that [1] discussed since 2006). Because of this, each time abranch is
created, authz rules have to be copied and modified for the newbranch.
This leads to a proliferation of authz rules; our authz is currently about2000 lines
and growing. I am currently implementing a post-commit script sothat we would be
able to record authz rules on files/directories, and authzwould be appended with
new rules every time these files/directories arecopied.
CollabNet TeamForge supports wildcard rules:
http://blogs.collab.net/teamforge/wildcard-access-control-and-path-based-permissions-in-teamforge[2]
Interesting. How did they deal with the concern raised in issue #2662 (i.e., the need
to walk the tree below a certain path to check if any of the other rules apply to any
descendant path)?
First, I am wondering how well such 'authz' approach would scale. Has anyonerun
scalability tests on authz?
So your question is whether at a certain size does it slow down? I recall in the past
it being said that it was stored in a hash so performance should not vary. But there
has to be a parsing slow down and possible memory bloat. That said, I have heard of
files in the hundred thousands for lines.
Yes, that was the question.
Note that you can also have files per repository.
We do not want to split the repository unless absolutely necessary, as that would
break the atomicity of commits for features touching both restricted and
unrestricted parts of the repository. Instead, I think, it would be very handy if the
access rights were copied along with the file/directory on which they are specified.
Second, I thought that if I am using properties to track authz-controlledfiles, SVN
server would probably do that more effectively than a post-commitscript. As an
added value, property-based authz would allow versioning inpath-based auth
configuration that current mechanism does not allow. E.g.,currently one could
either configure path /foo as either R/O, R/W orunaccessible to user U; it is not
possible to configure the path to beunaccessible before/after a certain revision.
Someone could always contribute it. I do not think it would scale well but if it were
optional then you could make the decision for yourself. Authz rules are expensive
to apply. If SVN had to do additional repository I/O to check for and fetch
properties it would only get worse.
I'll probably have a stab at it. One of the goals of this post was to check if there are
any objections to such feature that would make such development worthless /ab
initio/.
Regards,
Alexey.
--------
[1] mailto:stilor_at_att.net
[2] http://blogs.collab.net/teamforge/wildcard-access-control-and-path-based-permissions-in-teamforge
Received on 2013-10-17 23:40:38 CEST