Philip, sorry for the delay in response (I was out of office).
I have carefully considered the include-based approach for this feature,
however, there probably are some drawbacks compared to the approach with the
groups file directive:
- Potential security issues in certain delegation scenarios. Consider a
case when there is a Subversion server with multiple per-project repositories,
an administrator, who performed its initial configuration and project
managers, who are responsible for configuring the access rules for
those repositories:
* With includes in the configuration files an evil-doer could perform
cross-repository configuration includes. That theoretically allows
examininig the authorization rules for restricted repositories (e.g. via
bruteforce).
* As far as I understand, including huge arbitrary files for a single
repository could potentially hang the whole server.
* Includes add dynamic behavior in the authz scheme. Without them, the
server administrator configures a static set of files used for the
authorization process. With includes, however, this set it is no longer
static — users can tell the server, which files it should use to perform
the authz process.
- Includes might require merging of access rules and configuration chunks from
multiple files. With merging the whole authorization scheme could easily
become unobvious and sort of counterintuitive.
- Finally, the solution with a new directive follows the pattern already used
(just add a new option — as it was done with AuthzSVNReposRelativeAccessFile).
Regards,
Evgeny Kotkov
On Fri, Jan 25, 2013 at 2:30 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Ivan Zhakov <ivan_at_visualsvn.com> writes:
>
>> On Wed, Jan 23, 2013 at 7:27 PM, Evgeny Kotkov
>> <evgeny.kotkov_at_visualsvn.com> wrote:
>>> When AuthzSVNReposRelativeAccessFile directive is being used and
>>> authorization rules are stored per-repository, it is usually required to
>>> have a single set of groups for all repositories.
>>>
>>> In other words, there can be a 'developers' group, whose members should
>>> have access to all repositories. To avoid the duplication of the 'developers'
>>> group definition across multiple authz files, it would be great to have a
>>> single place to define these groups.
>>>
>>> The attached patch adds the 'AuthzSVNGroupsFile' option to specify the
>>> dedicated file where the group definitions are stored.
>>>
>> Committed in r1438407. Thanks!
>
> Are administrators going to want both relative path and absolute path
> versions of this directive?
>
> I wonder if we should implement some sort of generic include mechanism
> instead. Trac uses an INI compatible mechanism:
>
> [inherit]
> file = path/to/another/file
>
> we could
>
> [inherit]
> file = path/to/another/file
> relative_file = path/to/another/file
>
> and combines the values from the other files with the current file.
>
> I suppose this approach would break the meaning of existing authz files
> already using '[inherit]'. Another approach would be to use some
> non-INI syntax to define include files.
>
> --
> Certified & Supported Apache Subversion Downloads:
> http://www.wandisco.com/subversion/download
Received on 2013-01-28 10:08:45 CET