On Tue, Jan 17, 2012 at 2:54 PM, Johan Corveleyn <jcor...@gmail.com> wrote: > On Tue, Jan 17, 2012 at 5:36 PM, Paul Burba <ptbu...@gmail.com> wrote: >> On Mon, Jan 16, 2012 at 8:28 PM, Hyrum K Wright >> <hyrum.wri...@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
