On 11/28/2014 12:03 PM, Hannes Reich wrote:
> Hi,
>
> I'd like to suggest an extension to the authz file format to support the
> following scenario:
>
> * Some users of the repository should have access to everything, others
> should be restricted to a small set of "public" directories.
>
> * All users should be able to check out from the same "root" directory.
> Restricted users should get a sparse checkout containing only the
> public directories.
>
[...]
> Implementation:
> ---------------
>
> svn_repos_authz_check_access distinguishes between checks for recursive
> and non-recursive access. I have a small patch that grants
> non-recursive access if any subpath of the requested path grants
> ancestor permission (using the "a" specifier as in the example).
>
> This is similar to the scanning of subpath permissions to check for
> recursive access. The patch appears to work well for my use case.
>
> Does this seem like a generally worthwhile feature and/or sensible way
> of implementing it?
I love the idea of the feature, and in fact began at one point in the
past trying to provide similar functionality on the authz-overhaul
branch. Some reference points:
http://subversion.tigris.org/issues/show_bug.cgi?id=3380
http://svn.apache.org/repos/asf/subversion/branches/authz-overhaul/BRANCH-README
I had planned to make this a non-optional change of behavior, though,
and wasn't planning to introduce any new access codes to the authz
format. I was also trying to solve the problem in a way that would work
even for folks not using mod_authz_svn for access control. But that
turned out to be a pretty bit bite to chew.
Your approach might be a better one because a) its scope is manageable,
b) it doesn't change the interpretation of any existing authz files, and
b) it's explicit in its access grants rather than requiring Subversion
to extrapolate "traversability" by exploring the readability of the path
space below each directory.
Alas, I haven't the time to devote any real attention to your patch or
subsequent iterations thereof. But I thought I'd at least respond with
a bit of encouragement.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2014-12-02 16:52:03 CET