You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Carlos Alberto Costa Beppler <be...@gmail.com> on 2005/11/28 21:10:36 UTC
Multiple access filess when using SVNParentPath
+1 for a new feature where I can specify that the AuthzSVNAccessFile
is a relative path to the repository repository location (using the
conf directory as base by example).
This can be very useful when using SVNParentPath and delegating the
administration of the access control.
To not break the compability with existing configuration this could be
enabled by adding a new command to mod_authz_svn like
"AuthzSVNRelativePath" or something like this.
Example:
Today I have:
<Location /XSU/CadastroClientes>
DAV svn
SVNPath "C:/MPS/project/SVN/repos/XSU/CadastroClientes"
SVNIndexXSLT "/svnindex.xsl"
SVNAutoversioning On
AuthzSVNAccessFile "C:/MPS/project/SVN/repos/XSU/Projetos/conf/access.conf"
</Location>
<Location /XSU/Projetos>
DAV svn
SVNPath "C:/MPS/project/SVN/repos/XSU/Projetos"
SVNIndexXSLT "/svnindex.xsl"
SVNAutoversioning On
AuthzSVNAccessFile "C:/MPS/project/SVN/repos/XSU/Projetos/conf/access.conf"
</Location>
<Location /XSU/SALT>
DAV svn
SVNPath "C:/MPS/project/SVN/repos/XSU/SALT"
SVNIndexXSLT "/svnindex.xsl"
SVNAutoversioning On
AuthzSVNAccessFile "C:/MPS/project/SVN/repos/XSU/SALT/conf/access.conf"
</Location>
This could be like this:
<Location /XSU>
DAV svn
SVNParentPath "C:/MPS/project/SVN/repos/XSU"
SVNIndexXSLT "/svnindex.xsl"
SVNAutoversioning On
AuthzSVNRelativePath On
AuthzSVNAccessFile "access.conf"
</Location>
Re: Multiple access filess when using SVNParentPath
Posted by Carlos Alberto Costa Beppler <be...@gmail.com>.
I like this idea, but how to solve the name clash in groups
definition. Specially if there are different people editing the
"subfiles"
On 12/1/05, Ben Collins-Sussman <su...@red-bean.com> wrote:
> Actually, if there's enough inertia to add a new feature here, I'd
> much rather see the authz-policy file gain the ability to "#include"
> sub-files, much like the way httpd.conf is able to do. (Somebody here
> already suggested that.)
>
> In addition to solving the original poster's problem, it will add
> general flexibility.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Re: Multiple access filess when using SVNParentPath
Posted by Michael Sinz <Mi...@sinz.org>.
Max Bowsher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ben Collins-Sussman wrote:
>
>>Actually, if there's enough inertia to add a new feature here, I'd
>>much rather see the authz-policy file gain the ability to "#include"
>>sub-files, much like the way httpd.conf is able to do. (Somebody here
>>already suggested that.)
>>
>>In addition to solving the original poster's problem, it will add
>>general flexibility.
>
>
> It doesn't solve the OP's problem, unless you have a complicated include
> system which doesn't just include, but also allows you to restrict
> included files to affect only a specific repository.
>
> In view of this, I don't really see what benefit an include capability
> gives.
I was the one that initially brought up the include option - mainly as a
way to split the file without having to do as much of a change. I did not
intend the include mechanism to enforce anything - just to enable the
external enforcement of "file a for repository a"
I would much rather have the system natively understand this for various
reasons...
> Note that the servers re-load and re-parse the config file for every
> connection - in the case of HTTP, this is a lot, and having to do this
> for multiple files could get quite unpleasant.
This is where having the auth file per repository would help - only the
auth file for the path/repository being requested would need to be read
in any one request. This could be a significant savings (albeit reasonable
in-core caching of the last read with timestamp checks would provide much
of the same benefit)
> Then, there is the difficultly of defining how to merge conflicting
> statements between multiple files.
>
> At the moment, I don't understand any use-cases for include.
Like I said, the rules would be to treat it just as a single file (other
than being able to have multiple groups sections - maybe)
Anyway, I would much rather have the per-repository authentication file.
I believe it would be able to provide the biggest benefits.
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple access filess when using SVNParentPath
Posted by Max Bowsher <ma...@ukf.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ben Collins-Sussman wrote:
> Actually, if there's enough inertia to add a new feature here, I'd
> much rather see the authz-policy file gain the ability to "#include"
> sub-files, much like the way httpd.conf is able to do. (Somebody here
> already suggested that.)
>
> In addition to solving the original poster's problem, it will add
> general flexibility.
It doesn't solve the OP's problem, unless you have a complicated include
system which doesn't just include, but also allows you to restrict
included files to affect only a specific repository.
In view of this, I don't really see what benefit an include capability
gives.
Note that the servers re-load and re-parse the config file for every
connection - in the case of HTTP, this is a lot, and having to do this
for multiple files could get quite unpleasant.
Then, there is the difficultly of defining how to merge conflicting
statements between multiple files.
At the moment, I don't understand any use-cases for include.
Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDj4DcfFNSmcDyxYARAnHTAJ9gcPrQn+W56ibGE6OIcSBePpeeCQCgylhI
g9mvS/e88SCyF3uU6f9X558=
=up/t
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple access filess when using SVNParentPath
Posted by Ben Collins-Sussman <su...@red-bean.com>.
Actually, if there's enough inertia to add a new feature here, I'd
much rather see the authz-policy file gain the ability to "#include"
sub-files, much like the way httpd.conf is able to do. (Somebody here
already suggested that.)
In addition to solving the original poster's problem, it will add
general flexibility.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple access filess when using SVNParentPath
Posted by Michael Sinz <Mi...@sinz.org>.
Ximon Eighteen wrote:
> Michael Sinz wrote:
>
>>On 12/1/05, Max Bowsher <ma...@ukf.net> wrote:
>>
>>>Michael Sinz wrote:
>>
>>[...]
>>
>>>>That way it would be the "authz" file in each repository.
>>>>
>>>>The option would be something like:
>>>>
>>>> AuthzSVNPerRepository On
>>>
>>>This has the disadvantage that the directive meaning is changed by
>>>another, potentially appearing many lines distant.
>>>
>>>I'd suggest instead:
>>>
>>>AuthzSVNAccessFileInRepository my-authz-file
>
> I misread the suggestion and took it to mean that the file to reference
> is stored *in* a subversion repository. The follow up post saying "where
> would that live" made me realise I misunderstood, but also the idea of
> the control file living in the repository struck me as kinda cool, e.g.
> obey the head revision of this path, where path can be a repository URL
> (though a remote URL would be daft).
>
> Then another thought crossed my tired brain: PostgreSQL has database
> tables representing its' state and I'm sure there's an example I can't
> quite bring to mind of a system storing its' settings in itself... made
> me think of a repository server having a special repository which is
> used to store its config with the benefit of versioning changes to the
> config.
I actually do this in the Insurrection tools. All of the authentication
and access control files are stored in a authentication repository. Every
password change, access rights change, etc. are all tracked in the repository
with log messages that say who did what (and when, from the rev date)
This basically provides an audit trail of the operations and also allows
me to manually edit the files from a secure SVN checkout/commit. (I have
a post-commit hook script that checks out the new commit into the server's
authentication directory.)
> Call me crazy, just thought it was interesting. Not thought through,
> probably lots of holes in the idea. Apologies for hijacking the thread,
> please start a new thread if there are replies to this.
I would not put the auth file into the repository it is controlling. But
having the files in a repository is a very good idea and one that I already
use external scripts to enforce. I find it works well. Now the only reason
to log into the server is to build and install newer versions of Subversion.
Everything else happens via the repository. (And even the build directory
and source are a build repository)
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple access filess when using SVNParentPath
Posted by Ximon Eighteen <xi...@int.greenpeace.org>.
Michael Sinz wrote:
> On 12/1/05, Max Bowsher <ma...@ukf.net> wrote:
>
>>Michael Sinz wrote:
>
> [...]
>
>>>That way it would be the "authz" file in each repository.
>>>
>>>The option would be something like:
>>>
>>> AuthzSVNPerRepository On
>>
>>This has the disadvantage that the directive meaning is changed by
>>another, potentially appearing many lines distant.
>>
>>I'd suggest instead:
>>
>>AuthzSVNAccessFileInRepository my-authz-file
I misread the suggestion and took it to mean that the file to reference
is stored *in* a subversion repository. The follow up post saying "where
would that live" made me realise I misunderstood, but also the idea of
the control file living in the repository struck me as kinda cool, e.g.
obey the head revision of this path, where path can be a repository URL
(though a remote URL would be daft).
Then another thought crossed my tired brain: PostgreSQL has database
tables representing its' state and I'm sure there's an example I can't
quite bring to mind of a system storing its' settings in itself... made
me think of a repository server having a special repository which is
used to store its config with the benefit of versioning changes to the
config.
Call me crazy, just thought it was interesting. Not thought through,
probably lots of holes in the idea. Apologies for hijacking the thread,
please start a new thread if there are replies to this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple access filess when using SVNParentPath
Posted by Michael Sinz <Mi...@sinz.org>.
On 12/1/05, Max Bowsher <ma...@ukf.net> wrote:
> Michael Sinz wrote:
[...]
> > That way it would be the "authz" file in each repository.
> >
> > The option would be something like:
> >
> > AuthzSVNPerRepository On
>
> This has the disadvantage that the directive meaning is changed by
> another, potentially appearing many lines distant.
>
> I'd suggest instead:
>
> AuthzSVNAccessFileInRepository my-authz-file
I'm fine with that - where would the file live? (I would suggest the
conf directory since there is already authentication information in
that directory for other access methods.)
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:Michael.Sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple access filess when using SVNParentPath
Posted by Max Bowsher <ma...@ukf.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Sinz wrote:
> On 12/1/05, Max Bowsher <ma...@ukf.net> wrote:
>
>>>I too would like to add a measure of support/request for such a feature.
>>>It would make supporting large numbers of repositories with various
>>>administrative controls much more scalable.
>>
>>I think it's a reasonable request.
>>
>>However, it cannot be done simply with a relative path in the
>>AuthzSVNAccessFile directive, because this already has a meaning: it
>>looks for the authzfile relative to Apache's ServerRoot - which is kind
>>of expected behaviour, since other directives such as Include or
>>AuthUserFile so the same thing.
>
>
> That is understandable. I would think it would need to be a
> different option and that then this file would be part of the
> repository tree (beside the hooks directory or in the conf
> directory?)
>
> That way it would be the "authz" file in each repository.
>
> The option would be something like:
>
> AuthzSVNPerRepository On
This has the disadvantage that the directive meaning is changed by
another, potentially appearing many lines distant.
I'd suggest instead:
AuthzSVNAccessFileInRepository my-authz-file
Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDj1bQfFNSmcDyxYARAgD6AKCBcM3d6eIzMpXnsoogL5eG43RtbgCfRrDM
EFWIB0s6nIS5BLYogZ4ytK4=
=KeAx
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple access filess when using SVNParentPath
Posted by Michael Sinz <Mi...@sinz.org>.
On 12/1/05, Max Bowsher <ma...@ukf.net> wrote:
> > I too would like to add a measure of support/request for such a feature.
> > It would make supporting large numbers of repositories with various
> > administrative controls much more scalable.
>
> I think it's a reasonable request.
>
> However, it cannot be done simply with a relative path in the
> AuthzSVNAccessFile directive, because this already has a meaning: it
> looks for the authzfile relative to Apache's ServerRoot - which is kind
> of expected behaviour, since other directives such as Include or
> AuthUserFile so the same thing.
That is understandable. I would think it would need to be a
different option and that then this file would be part of the
repository tree (beside the hooks directory or in the conf
directory?)
That way it would be the "authz" file in each repository.
The option would be something like:
AuthzSVNPerRepository On
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:Michael.Sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple access filess when using SVNParentPath
Posted by Max Bowsher <ma...@ukf.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Sinz wrote:
> Carlos Alberto Costa Beppler wrote:
>
>> I really don´t know in any other places, but here it would be very
>> cool if I could separate the access files. Every other configuration
>> is the same for all repositories.
>
>
> I too would like to add a measure of support/request for such a feature.
> It would make supporting large numbers of repositories with various
> administrative controls much more scalable.
I think it's a reasonable request.
However, it cannot be done simply with a relative path in the
AuthzSVNAccessFile directive, because this already has a meaning: it
looks for the authzfile relative to Apache's ServerRoot - which is kind
of expected behaviour, since other directives such as Include or
AuthUserFile so the same thing.
Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDj0kBfFNSmcDyxYARArx0AKCatrwePkuKU84WvU+usLRH7XyaKQCglH24
eKK1NJnhgPf8B0ndrzHZ734=
=LbC9
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple access filess when using SVNParentPath
Posted by Michael Sinz <Mi...@sinz.org>.
Carlos Alberto Costa Beppler wrote:
> I really don´t know in any other places, but here it would be very
> cool if I could separate the access files. Every other configuration
> is the same for all repositories.
I too would like to add a measure of support/request for such a feature.
It would make supporting large numbers of repositories with various
administrative controls much more scalable.
It may also help with other performance issues for when the access file
starts getting large (200+ developers in some projects, about 30 different
projects, each with release manager for write access to release tags,
developers with write access to trunk and branches or only to specific
branches, etc. The size of the file has almost gotten out of control.
[...]
> But if it is difficult to implement, I will try another approach to
> delegate the access control.
I have built various administrative tools for various clients. Plus I
have the tool that is part of Insurrection (still does not do fine-grained
path access control...) Having a file per repository could simplify many
of the issues I have had in the various solutions - but for now I have
solutions that work so if this is too complex/hard to provide, I can live
without for now.
PS - if not supporting this concept directly within mod_auth_svn, how
about adding an include directive to the authentication file. This way
it could be "simulated" from a relatively static authentication file
that includes each of the repository files. (Albeit I would think that
just supporting the per-repository file would be almost as easy.)
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple access filess when using SVNParentPath
Posted by Carlos Alberto Costa Beppler <be...@gmail.com>.
I really don´t know in any other places, but here it would be very
cool if I could separate the access files. Every other configuration
is the same for all repositories.
We use mod_auth_sspi for authentication at / level on Apache ans since
today we use mod_macro to simplify the configuration of repositories.
The only difference is the access control that is very different for
every repository. It is based on the development team responsible by
the project stored on that repository. The manager of each project is
responsible to give or revoke access based on changes on his staff.
Today every change is reported to us and we are responsible to give or
revoke the access no repository.
But if it is difficult to implement, I will try another approach to
delegate the access control.
On 11/28/05, Ben Collins-Sussman <su...@red-bean.com> wrote:
> Hm, that seems like pretty unusual use-case. Admins are the ones who
> typically manage authz policy files, not arbitrary groups of users.
>
> I guess I'm skeptical that there's really a problem to solve here.
> In one corner, the SVNParentPath feature allows a group of
> repositories to share a single configuration: authentication,
> authorization, and so on. In the other corner, SVNPath allows
> individual repositories to be individually configured. What you're
> proposing is a new feature that starts to blur the lines between the
> two existing features. The minor convenience you'd get doesn't seem
> worth the extra code (and UI) complexity that would be added to
> subversion.
>
> Maybe others feel differently.
>
>
> On 11/28/05, Carlos Alberto Costa Beppler <be...@gmail.com> wrote:
> > Because different people will have access to modify the policy and I
> > can not give them rights to modify only parts of the file.
> >
> > On 11/28/05, Ben Collins-Sussman <su...@red-bean.com> wrote:
> > > On 11/28/05, Carlos Alberto Costa Beppler <be...@gmail.com> wrote:
> > > > +1 for a new feature where I can specify that the AuthzSVNAccessFile
> > > > is a relative path to the repository repository location (using the
> > > > conf directory as base by example).
> > > >
> > > > This can be very useful when using SVNParentPath and delegating the
> > > > administration of the access control.
> > > >
> > > > To not break the compability with existing configuration this could be
> > > > enabled by adding a new command to mod_authz_svn like
> > > > "AuthzSVNRelativePath" or something like this.
> > > >
> > >
> > > I don't understand, why do you want separate authz-policy files for
> > > separate repositories, when you can already control access to *all* of
> > > them with a single policy file?
> > >
> >
>
Re: Multiple access filess when using SVNParentPath
Posted by Carlos Alberto Costa Beppler <be...@gmail.com>.
This is exactly what I want.
Using SVNPath it works very well, except I must restart the server
every time I create a new repository.
On 12/8/05, Branko Čibej <br...@xbc.nu> wrote:
> Ben Collins-Sussman wrote:
> > Hm, that seems like pretty unusual use-case. Admins are the ones who
> > typically manage authz policy files, not arbitrary groups of users.
> >
> Yes. The devil lies in the definition of "admin" -- specifically,
> "server admin" vs. "repository admin".
>
> At work, I created a similar setup (without the SVNParentPath) -- the
> server admin can create repositories, but the repository admin can edit
> the mod_dav_svn authz.conf file, which is stored in the repository
> itself. That way, project managers can add or remove peoples' access to
> the project's repository without having to bug the IT department -- or,
> worse yet, me! :)
>
> -- Brane
>
>
Re: Multiple access filess when using SVNParentPath
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
> Hm, that seems like pretty unusual use-case. Admins are the ones who
> typically manage authz policy files, not arbitrary groups of users.
>
Yes. The devil lies in the definition of "admin" -- specifically,
"server admin" vs. "repository admin".
At work, I created a similar setup (without the SVNParentPath) -- the
server admin can create repositories, but the repository admin can edit
the mod_dav_svn authz.conf file, which is stored in the repository
itself. That way, project managers can add or remove peoples' access to
the project's repository without having to bug the IT department -- or,
worse yet, me! :)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple access filess when using SVNParentPath
Posted by Ivan Zhakov <ch...@gmail.com>.
On 11/29/05, Ben Collins-Sussman <su...@red-bean.com> wrote:
> Hm, that seems like pretty unusual use-case. Admins are the ones who
> typically manage authz policy files, not arbitrary groups of users.
You aren't right.In my company lead developers manage authz policy
files for their repositories. Admins became crazy if they mange authz
files for 200+ developers :)
> On 11/28/05, Carlos Alberto Costa Beppler <be...@gmail.com> wrote:
> > Because different people will have access to modify the policy and I
> > can not give them rights to modify only parts of the file.
> >
> > On 11/28/05, Ben Collins-Sussman <su...@red-bean.com> wrote:
> > > On 11/28/05, Carlos Alberto Costa Beppler <be...@gmail.com> wrote:
> > > > +1 for a new feature where I can specify that the AuthzSVNAccessFile
> > > > is a relative path to the repository repository location (using the
> > > > conf directory as base by example).
> > > >
> > > > This can be very useful when using SVNParentPath and delegating the
> > > > administration of the access control.
> > > >
> > > > To not break the compability with existing configuration this could be
> > > > enabled by adding a new command to mod_authz_svn like
> > > > "AuthzSVNRelativePath" or something like this.
> > > >
> > >
> > > I don't understand, why do you want separate authz-policy files for
> > > separate repositories, when you can already control access to *all* of
> > > them with a single policy file?
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
--
Ivan Zhakov
Re: Multiple access filess when using SVNParentPath
Posted by Ben Collins-Sussman <su...@red-bean.com>.
Hm, that seems like pretty unusual use-case. Admins are the ones who
typically manage authz policy files, not arbitrary groups of users.
I guess I'm skeptical that there's really a problem to solve here.
In one corner, the SVNParentPath feature allows a group of
repositories to share a single configuration: authentication,
authorization, and so on. In the other corner, SVNPath allows
individual repositories to be individually configured. What you're
proposing is a new feature that starts to blur the lines between the
two existing features. The minor convenience you'd get doesn't seem
worth the extra code (and UI) complexity that would be added to
subversion.
Maybe others feel differently.
On 11/28/05, Carlos Alberto Costa Beppler <be...@gmail.com> wrote:
> Because different people will have access to modify the policy and I
> can not give them rights to modify only parts of the file.
>
> On 11/28/05, Ben Collins-Sussman <su...@red-bean.com> wrote:
> > On 11/28/05, Carlos Alberto Costa Beppler <be...@gmail.com> wrote:
> > > +1 for a new feature where I can specify that the AuthzSVNAccessFile
> > > is a relative path to the repository repository location (using the
> > > conf directory as base by example).
> > >
> > > This can be very useful when using SVNParentPath and delegating the
> > > administration of the access control.
> > >
> > > To not break the compability with existing configuration this could be
> > > enabled by adding a new command to mod_authz_svn like
> > > "AuthzSVNRelativePath" or something like this.
> > >
> >
> > I don't understand, why do you want separate authz-policy files for
> > separate repositories, when you can already control access to *all* of
> > them with a single policy file?
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple access filess when using SVNParentPath
Posted by Ivan Zhakov <ch...@gmail.com>.
On 11/29/05, Carlos Alberto Costa Beppler <be...@gmail.com> wrote:
> Because different people will have access to modify the policy and I
> can not give them rights to modify only parts of the file.
In my company I use Apache module mod_macro and repository
configuration take one line (Use SvnRepos test-repo). Also I place
configuration for each repos in separate file to easy detaching for
admin operations.
> On 11/28/05, Ben Collins-Sussman <su...@red-bean.com> wrote:
> > On 11/28/05, Carlos Alberto Costa Beppler <be...@gmail.com> wrote:
> > > +1 for a new feature where I can specify that the AuthzSVNAccessFile
> > > is a relative path to the repository repository location (using the
> > > conf directory as base by example).
> > >
> > > This can be very useful when using SVNParentPath and delegating the
> > > administration of the access control.
> > >
> > > To not break the compability with existing configuration this could be
> > > enabled by adding a new command to mod_authz_svn like
> > > "AuthzSVNRelativePath" or something like this.
> > >
> >
> > I don't understand, why do you want separate authz-policy files for
> > separate repositories, when you can already control access to *all* of
> > them with a single policy file?
> >
>
--
Ivan Zhakov
Re: Multiple access filess when using SVNParentPath
Posted by Carlos Alberto Costa Beppler <be...@gmail.com>.
Because different people will have access to modify the policy and I
can not give them rights to modify only parts of the file.
On 11/28/05, Ben Collins-Sussman <su...@red-bean.com> wrote:
> On 11/28/05, Carlos Alberto Costa Beppler <be...@gmail.com> wrote:
> > +1 for a new feature where I can specify that the AuthzSVNAccessFile
> > is a relative path to the repository repository location (using the
> > conf directory as base by example).
> >
> > This can be very useful when using SVNParentPath and delegating the
> > administration of the access control.
> >
> > To not break the compability with existing configuration this could be
> > enabled by adding a new command to mod_authz_svn like
> > "AuthzSVNRelativePath" or something like this.
> >
>
> I don't understand, why do you want separate authz-policy files for
> separate repositories, when you can already control access to *all* of
> them with a single policy file?
>
Re: Multiple access filess when using SVNParentPath
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 11/28/05, Carlos Alberto Costa Beppler <be...@gmail.com> wrote:
> +1 for a new feature where I can specify that the AuthzSVNAccessFile
> is a relative path to the repository repository location (using the
> conf directory as base by example).
>
> This can be very useful when using SVNParentPath and delegating the
> administration of the access control.
>
> To not break the compability with existing configuration this could be
> enabled by adding a new command to mod_authz_svn like
> "AuthzSVNRelativePath" or something like this.
>
I don't understand, why do you want separate authz-policy files for
separate repositories, when you can already control access to *all* of
them with a single policy file?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple access filess when using SVNParentPath
Posted by Carlos Alberto Costa Beppler <be...@gmail.com>.
I prefer this too. I only proposed the auxiliar configuration becaus I
don´t know if it is simple to detect a relative path on all platforms.
On 11/29/05, Alan Barrett <ap...@cequrux.com> wrote:
> On Mon, 28 Nov 2005, Carlos Alberto Costa Beppler wrote:
> > To not break the compability with existing configuration this could be
> > enabled by adding a new command to mod_authz_svn like
> > "AuthzSVNRelativePath" or something like this.
>
> > AuthzSVNRelativePath On
> > AuthzSVNAccessFile "access.conf"
>
> I don't care much either way about this feature, but if you do add it,
> please do it in a way that does not need the ugly "AuthzSVNRelativePath
> On". I see no technical reason why the code could not automatically
> detect whether AuthzSVNAccessFile is an absolute or a relative path.
> (e.g., absolute paths start with "/" or something OS-dependent; relative
> paths start with "./" or "../" or something OS-dependent; or just access
> the files in a way that uses the OS to do the right thing, via the moral
> equivalent of "cd somedir ; open file".)
>
> --apb (Alan Barrett)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Re: Multiple access filess when using SVNParentPath
Posted by Alan Barrett <ap...@cequrux.com>.
On Mon, 28 Nov 2005, Carlos Alberto Costa Beppler wrote:
> To not break the compability with existing configuration this could be
> enabled by adding a new command to mod_authz_svn like
> "AuthzSVNRelativePath" or something like this.
> AuthzSVNRelativePath On
> AuthzSVNAccessFile "access.conf"
I don't care much either way about this feature, but if you do add it,
please do it in a way that does not need the ugly "AuthzSVNRelativePath
On". I see no technical reason why the code could not automatically
detect whether AuthzSVNAccessFile is an absolute or a relative path.
(e.g., absolute paths start with "/" or something OS-dependent; relative
paths start with "./" or "../" or something OS-dependent; or just access
the files in a way that uses the OS to do the right thing, via the moral
equivalent of "cd somedir ; open file".)
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org