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. Currently, the authz configuration for such a setup is verbose, and requires constant maintenance: I must grant restricted users read access on all ancestors of the public directories, and deny it on all other children of those ancestors. When new content is added to the repository anywhere along the chain of ancestors, it becomes "public" by default unless I add a new authz section for it. This could be simplified by introducing the concept of "ancestor permissions": A single permission setting that applies to the given path and all its ancestors, but is not inherited by other children of those ancestors. An example: ----------- If the repo contains directories named /secret1/ /A/B/secret2/ /A/C/public1/ /D/public2/ ...then these authz rules will grant access to the two "public" paths: [/A/C/public1] restricted=r [/D/public2] restricted=r ...but to enable a single checkout containing them both, we also need [/] restricted=r ...which enables access to the ancestor directories, followed by [/secret1] restricted= [/A/B] restricted= ...to avoid granting access to the "secret" directories. If we create "/A/E/F/G/H/secret3" at some future time, then we must remember to add a new rule [/A/E] restricted= ...or the restricted users will have access to it as a result of the permission on "/". That's a lot of configuration for a IMHO simple requirement. With ancestor permissions, all of the above could be expressed as [/A/C/public1] restricted=ra [/D/public2] restricted=ra which implies read access to "/", "/A", "/A/C" and "/D", but not to their children. 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? Thanks for any feedback, /Hannes
