[PATCH] Re: Ancestor directory permissions in authz

[Hannes Reich <ha...@skynet.ie>]

On 02/12/14 16:49, C. Michael Pilato wrote:
> On 11/28/2014 12:03 PM, Hannes Reich wrote:
>> 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.

> 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.

Thanks for the encouragement and background information.

I've attached the patch, which I would describe as a workaround for the 
underlying issue the authz-overhaul branch is addressing.

Since the patch lacks authz-overhaul's concept of "list access", the 
"ancestor" permission has some side-effects:

- Users can learn of the existence of the siblings of all ancestors of 
paths to which they have access (by poking around in .svn/wc.db). This 
is suboptimal but acceptable for my use case.

- Users can access the properties of all ancestors of paths to which 
they have access. Perhaps this can be construed as a feature since it 
enables access to svn:mergeinfo, though I haven't explored how well 
merges as a restricted user work in practice.

/Hannes

Re: Re: [PATCH] Re: Ancestor directory permissions in authz

[Hannes Reich <ha...@skynet.ie>]

On 11/12/14 17:14, Branko Čibej wrote:
 > I have to admit I'm having a bit of trouble understanding what the
 > patch is supposed to do. Can you please explain, with examples, what
 > you're trying to achieve?

Do the examples in my first mail of this thread help?

http://mail-archives.apache.org/mod_mbox/subversion-dev/201411.mbox/%3C5478AAD4.3070306%40skynet.ie%3E

 > FWIW, I've been looking at adding directory traversal permission to
 > authz: this permission means you're allowed to know about the existence
 > of a path, but not its contents (i.e, know that a directory exists, and
 > even lookup specific children by name, but not read the directory
 > contents).

That sounds like the authz-overhaul branch mentioned by C. Michael
Pilato.  Is it the same thing?

 > I suspect what you're trying to do is a fairly incomplete
 > subset of that.

I think it is a subset, plus a shorthand way of granting traversal
permission for all containing directories of a given path.

 > There's also ^/subversion/branches/authzperf, which implements wildcard
 > support for authz files (among other performance improvements). I
 > suspect that this would cover many of your use cases.

Wildcards in paths would solve the biggest problem I have with the
current authz implementation, namely the need to explicitly deny
permission on many paths.  I didn't go down that route myself because I
was worried about the performance impact of wildcard matching.

With wildcards, the resulting configuration for my scenario would still
be somewhat verbose and error prone.  If my reading of
https://wiki.apache.org/subversion/AuthzImprovements is correct, the
example from my first mail could be expressed as:

   [:glob:/**]
   restricted=
   [/]
   restricted=r
   [/A]
   restricted=r
   [/A/C]
   restricted=r
   [:glob:/A/C/public1/**]
   restricted=r
   [/D]
   restricted=r
   [:glob:/D/public2/**]
   restricted=r

That's 7 rules implement "The restricted user should be able to check
out /A/C/public1 and /D/public2 in a single working copy". I works, but
I would still prefer to write

   [/A/C/public1]
   restricted=ra
   [/D/public2]
   restricted=ra

/Hannes

Re: [PATCH] Re: Ancestor directory permissions in authz

[Branko Čibej <br...@wandisco.com>]

On 11.12.2014 14:37, Hannes Reich wrote:
> Thanks for the encouragement and background information.
>
> I've attached the patch, which I would describe as a workaround for
> the underlying issue the authz-overhaul branch is addressing.
>
> Since the patch lacks authz-overhaul's concept of "list access", the
> "ancestor" permission has some side-effects:
>
> - Users can learn of the existence of the siblings of all ancestors of
> paths to which they have access (by poking around in .svn/wc.db). This
> is suboptimal but acceptable for my use case.
>
> - Users can access the properties of all ancestors of paths to which
> they have access. Perhaps this can be construed as a feature since it
> enables access to svn:mergeinfo, though I haven't explored how well
> merges as a restricted user work in practice.

I have to admit I'm having a bit of trouble understanding what the patch
is supposed to do. Can you please explain, with examples, what you're
trying to achieve?

FWIW, I've been looking at adding directory traversal permission to
authz: this permission means you're allowed to know about the existence
of a path, but not its contents (i.e, know that a directory exists, and
even lookup specific children by name, but not read the directory
contents). I suspect what you're trying to do is a fairly incomplete
subset of that.

There's also ^/subversion/branches/authzperf, which implements wildcard
support for authz files (among other performance improvements). I
suspect that this would cover many of your use cases.

-- Brane