Re: [RFC] Server Dictated Configuration

On Tue, Jan 17, 2012 at 9:12 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Tue, Jan 17, 2012 at 2:54 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>> On Tue, Jan 17, 2012 at 5:36 PM, Paul Burba <ptburba_at_gmail.com> wrote:
>>> On Mon, Jan 16, 2012 at 8:28 PM, Hyrum K Wright
>>> <hyrum.wright_at_wandisco.com> wrote:
>>
>> [...]
>>
>>>> Another thing to note is that there have been some rumblings about
>>>> authz improvements, along the lines of an additional permission to say
>>>> "you can know about this directory".  I know C-Mike has been thinking
>>>> about this off-and-on since the 3242 debacle, and something like
>>>> inheritable props my fit in that model, though I'd had to make the
>>>> feature dependency tree another level deeper.
>>>
>>> Even if that was implemented today it's still an administrative
>>> nightmare, albeit a lesser one.  In the example above we'd need to
>>> give the new special permission to the repository root.  But the
>>> moment we start setting inheritable properties on subtrees, we'd also
>>> need to be sure that those subtrees have the special permission if all
>>> users with access under that subtree don't have access to the root of
>>> the subtree.
>>
>> But, but ... if you're able to checkout ^/foo/bar/baz, then you
>> already know that foo and foo/bar exist, don't you? If nothing else,
>> 'svn info' will tell you that.
>>
>> So essentially, if we're talking about path-wise ancestors, you always
>> know about those ancestors, there's no need to specifically configure
>> this in any way.
>
> Sure, *if* a path we have read access to can inherit an inheritable
> property from a parent we have no access to, then there is no problem.
>
> I was talking about the case where we want "inheritable" properties
> but don't want to allow inheritance in the case where we have no
> access to the parent.  I was trying to make the argument that these
> authz improvements alone (at least as I understand them, which isn't
> very well) are still problematic in this case.
>
> Does that make sense?

Yep, perfectly. Agreed that, whatever way it's implemented, you should
be able to read the inheritable props from ancestor paths, even if you
don't have authz access to those paths themselves.

>>> To condense to its essential core what I am proposing, it's this simple rule:
>>>
>>> "If a user has read access to a path, then that path can inherit
>>> inheritable properties from its path-wise ancestors, regardless of the
>>> user's permissions to those ancestors"
>>
>> Yep, makes perfect sense (exactly like you know about the existence of
>> those paths already, by being able to checkout them).
>
> Not to argue against myself, but I am proposing that we'll know more
> than mere existence, we'll know the a particular property is set and
> that property's value.  That information may come from a path we do
> not otherwise have access to.  Some folks might object to this (Hyrum
> certainly was wary of it).
>
> My response is: If you purposefully set an *inheritable* property on a
> parent path and then gave access to a child path, don't be surprised
> if the child can inherit that property.

Yep, agreed.

-- 
Johan