authz via properties?
Hi all, We are actively using authz path-based authentication rules: due to some legal requirements, some parts of our product source code are not accessible to a part of the developer team. Currently authz does not support wildcards (there is an issue about that [1] discussed since 2006). Because of this, each time a branch is created, authz rules have to be copied and modified for the new branch. This leads to a proliferation of authz rules; our authz is currently about 2000 lines and growing. I am currently implementing a post-commit script so that we would be able to record authz rules on files/directories, and authz would be appended with new rules every time these files/directories are copied. First, I am wondering how well such 'authz' approach would scale. Has anyone run scalability tests on authz? Second, I thought that if I am using properties to track authz-controlled files, SVN server would probably do that more effectively than a post-commit script. As an added value, property-based authz would allow versioning in path-based auth configuration that current mechanism does not allow. E.g., currently one could either configure path /foo as either R/O, R/W or unaccessible to user U; it is not possible to configure the path to be unaccessible before/after a certain revision. Thoughts? Ideas? Regards, Alexey. [1] http://subversion.tigris.org/issues/show_bug.cgi?id=2662
Re: authz via properties?
[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 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
Re: authz via properties?
On Thu, Oct 17, 2013 at 5:39 PM, Alexey Neyman wrote: > ** > > [Restored CC of the mailing list] > Did I only reply to you? Thanks for adding the list back. > On Thursday, October 17, 2013 03:24:45 PM Mark Phippard wrote: > > 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. > I was only pointing this out in case your existing rules were covering many repositories. If that were true, you can now have one authz file per repository rather than combining everything into a single file. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: authz via properties?
On 17.10.2013 20:00, Alexey Neyman wrote: > Hi all, > > We are actively using authz path-based authentication rules: due to some > legal > requirements, some parts of our product source code are not accessible to a > part of the developer team. Currently authz does not support wildcards (there > is an issue about that [1] discussed since 2006). Because of this, each time > a > branch is created, authz rules have to be copied and modified for the new > branch. > > This leads to a proliferation of authz rules; our authz is currently about > 2000 lines and growing. I am currently implementing a post-commit script so > that we would be able to record authz rules on files/directories, and authz > would be appended with new rules every time these files/directories are > copied. > > First, I am wondering how well such 'authz' approach would scale. Has anyone > run scalability tests on authz? > > Second, I thought that if I am using properties to track authz-controlled > files, SVN server would probably do that more effectively than a post-commit > script. As an added value, property-based authz would allow versioning in > path-based auth configuration that current mechanism does not allow. E.g., > currently one could either configure path /foo as either R/O, R/W or > unaccessible to user U; it is not possible to configure the path to be > unaccessible before/after a certain revision. > > Thoughts? Ideas? Properties are not suitable for storing ACLs because they are immutable; i.e., you cannot change properties on committed files and directories. You need a different kind of structure, one that the Subversion repository does not have yet. In-repository ACLs are a feature that's we'd like to add to the new repository back-end that's being developed. But don't hold your breath; it will be several years before this is available. In the meantime, one authz file per repository (and preferably stored /in/ the repository, which is a new feature in 1.8) is IMO the best available option. You can also use the pre-commit and pre-revprop-change hooks and build your own authz system around those, but that's a lot of work. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: authz via properties?
On Friday, October 18, 2013 02:46:39 AM Branko Čibej wrote: On 17.10.2013 20:00, Alexey Neyman wrote: Hi all, We are actively using authz path-based authentication rules: due to some legal requirements, some parts of our product source code are not accessible to a part of the developer team. Currently authz does not support wildcards (there is an issue about that [1] discussed since 2006). Because of this, each time a branch is created, authz rules have to be copied and modified for the new branch. This leads to a proliferation of authz rules; our authz is currently about 2000 lines and growing. I am currently implementing a post-commit script so that we would be able to record authz rules on files/directories, and authz would be appended with new rules every time these files/directories are copied. First, I am wondering how well such 'authz' approach would scale. Has anyone run scalability tests on authz? Second, I thought that if I am using properties to track authz-controlled files, SVN server would probably do that more effectively than a post-commit script. As an added value, property-based authz would allow versioning in path-based auth configuration that current mechanism does not allow. E.g., currently one could either configure path /foo as either R/O, R/W or unaccessible to user U; it is not possible to configure the path to be unaccessible before/after a certain revision. Thoughts? Ideas? Properties are not suitable for storing ACLs because they are immutable; i.e., you cannot change properties on committed files and directories. You need a different kind of structure, one that the Subversion repository does not have yet. Well, technically you can dump & reload... But that's hardly maintainable, I agree. Are those ACLs you're describing going to be version-specific? In other words, will it be possible to specify that /foo/bar@2345 is r/w for user harry, but not accessible starting with revision 2346? Thanks for a pointer to that 1.8 feature, I forgot about that. That might make my task a bit easier. Regards,Alexey. -- Branko Čibej | *Director of Subversion* WANdisco // /Non-Stop Data/ e. br...@wandisco.com[1] [1] mailto:br...@wandisco.com