[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 <sti...@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:sti...@att.net [2] http://blogs.collab.net/teamforge/wildcard-access-control-and-path-based-permissions-in-teamforge
