[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] Server Dictated Configuration

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Tue, 17 Jan 2012 20:54:50 +0100

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.

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

Received on 2012-01-17 20:55:44 CET

This is an archived mail posted to the Subversion Dev mailing list.