You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Alexey Neyman <st...@att.net> on 2013/10/17 21:00:09 UTC
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?
Posted by Alexey Neyman <st...@att.net>.
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. brane@wandisco.com[1]
--------
[1] mailto:brane@wandisco.com
Re: authz via properties?
Posted by Branko Čibej <br...@wandisco.com>.
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. brane@wandisco.com
Re: authz via properties?
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Oct 17, 2013 at 5:39 PM, Alexey Neyman <st...@att.net> 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?
Posted by Alexey Neyman <st...@att.net>.
[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@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@att.net
[2] http://blogs.collab.net/teamforge/wildcard-access-control-and-path-based-permissions-in-teamforge