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?
>> 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.
Paul
Received on 2012-01-17 21:13:22 CET