You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Luiz Guilherme Kimel <lk...@dba.com.br> on 2010/07/28 17:59:32 UTC
Path-Based Authorization for Tags
Hello there,
I'm implementing a subversion repository that keeps project management
artefacts. In other words, we are using SVN for document management. And
everything was going right until we find that managers need to keep status
of allocated human resources salaries and this can't be accessed by everyone
in the project. Ok, let's use path-based auth, but then comes a question:
what to do with tags?
Example path-based settings for a project:
[svn:/projects/project-abc/tags/]
@team=r
@cm=rw
[svn:/projects/project-abc/trunk/]
@team=rw
[svn:/projects/project-abc/trunk/releases]
@team=r
@cm=rw
[svn:/projects/project-abc/trunk/planning]
# no change
[svn:/projects/project-abc/trunk/costs]
@team=
@maganement=rw
My requirements:
1) I want that the "costs" directory will be writeable only by
management group while under the trunk folder;
2) I want that the "costs" directory will be readeable and just
readeable to management group once under tags folder;
3) I don't want to have to specify different path-based auth rules for
each new tag.
4) It's desireable that the configuration management group (cm group)
is able to generate tags, but still can't read the "costs" directory!
Am I dreaming? It would be wonderful if I were able to specify path-based
auth like this:
[svn:/projects/project-abc/tags/*/costs]
*=
@maganement=r
[svn:/projects/project-abc/trunk/costs]
*=
@maganement=rw
But I can't. I need to keep costs status linked to project baseline saved
when we have a complete milestone. I thought about an structure like this:
Project1
Team
Trunk
Planning
Branches
Tags
Tag-Initiation-finished
Tag-Planning-finished
Tag-Execution-finished
Management
Trunk
Costs
Branches
Tags
Tag-Initiation-finished
Tag-Planning-finished
Tag-Execution-finished
But it sounds too complex and shady to users. Any ideas?
Thank you!
Luiz Guilherme M. Kimel
Re: Path-Based Authorization for Tags
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Jul 28, 2010 at 7:59 PM, Luiz Guilherme Kimel <lk...@dba.com.br> wrote:
> Hello there,
>
>
>
> I’m implementing a subversion repository that keeps project management
> artefacts. In other words, we are using SVN for document management. And
> everything was going right until we find that managers need to keep status
> of allocated human resources salaries and this can’t be accessed by everyone
> in the project. Ok, let’s use path-based auth, but then comes a question:
> what to do with tags?
>
>
>
> Example path-based settings for a project:
>
>
>
> [svn:/projects/project-abc/tags/]
>
> @team=r
>
> @cm=rw
>
> [svn:/projects/project-abc/trunk/]
>
> @team=rw
>
> [svn:/projects/project-abc/trunk/releases]
>
> @team=r
>
> @cm=rw
>
> [svn:/projects/project-abc/trunk/planning]
>
> # no change
>
> [svn:/projects/project-abc/trunk/costs]
>
> @team=
>
> @maganement=rw
>
>
>
> My requirements:
>
>
>
> 1) I want that the “costs” directory will be writeable only by
> management group while under the trunk folder;
>
> 2) I want that the “costs” directory will be readeable and just
> readeable to management group once under tags folder;
>
> 3) I don’t want to have to specify different path-based auth rules for
> each new tag…
>
> 4) It’s desireable that the configuration management group (cm group)
> is able to generate tags, but still can’t read the “costs” directory!
>
>
>
> Am I dreaming? It would be wonderful if I were able to specify path-based
> auth like this:
>
>
>
> [svn:/projects/project-abc/tags/*/costs]
>
> *=
>
> @maganement=r
>
>
>
> [svn:/projects/project-abc/trunk/costs]
>
> *=
>
> @maganement=rw
>
Unfortunately, you can't do that right now.
FYI, there is an open enhancement request in the issue tracker for
this feature:
http://subversion.tigris.org/issues/show_bug.cgi?id=2662 - authz with wildcards
It seems to be a very useful feature, which comes up quite frequently
on this list. Some patches have been proposed in the issue tracker,
but for some reason they haven't been applied...
--
Johan