On 18.05.2015 15:08, C. Michael Pilato wrote:
> On 05/14/2015 08:12 AM, Branko Čibej wrote:
>> On 13.05.2015 15:24, C. Michael Pilato wrote:
>>> I lean towards thinking that falls outside the scope of acceptable
>>> changes in behavior in the 1.x line *unless* you can find a way to,
>>> via configuration, allow administrators to explicitly toggle this new
>>> paradigm.
>> I've been thinking about a reasonable way to do this. Config files are
>> out, IMO, because this should really be per-authz-file behaviour, not
>> per-server or per-repository.
>>
>> On the authzperf branch, we came up with an extended,
>> backward-compatible authz rule syntax that allows us to add different
>> options to authz rules without causing clashes with existing syntax
>> (see: "New Rule Syntax for Wildcard Rules" in
>> http://wiki.apache.org/subversion/AuthzImprovements).
>>
>> With that in mind, we could teach the trunk/1.9 authz parser to
>> recognize an optional "[:config:]" section, in which we could add
>> options that control the behaviour of the rules in the authz file; a
>> 'copy-target-requires-recursive-access' option could then control the
>> behaviour we've been discussing; whit the default, of course, being
>> 'true' for backwards compatibility.
> Heh, this is precisely what I meant with "via configuration". I just
> thought we'd already found a way to do in-authz-file configuration.
> Well, glad you guys were able to find a way to make that daydream a
> reality! :-)
Yes, well, it'll be a reality iff we radically change the authz callback
API in libsvn_repos; otherwise, no deal ... the callers of that API have
no access to the parsed authz structure, and the callback doesn't know
which operation we're checking authz for.
I think the solution is to stop asking what kind of access the user has
for a certain path, but instead to ask if the user can use the path for
the given operation (create, modify, delete, copy source, move source,
copy target, move target, etc.). This would let us nicely encapsulate
the authz "philosophy". Obviously this is not 1.9 material.
-- Brane
Received on 2015-05-19 06:24:33 CEST