Ancestor directory permissions in authz

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
Received on 2014-11-28 23:44:26 CET