You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Doug Robinson <do...@wandisco.com> on 2017/06/01 22:11:39 UTC
Re: Subversion AuthZ Wildcards
Stefan:
[sorry for the delay]
On Thu, May 18, 2017 at 9:38 AM, Stefan Fuhrmann <st...@apache.org> wrote:
> On 27.02.2017 17:05, Julian Foad wrote:
>
>> Doug Robinson wrote:
>>
>>> Folks:
>>>
>>> "Julian said Stefan said this could be useful." :-)
>>>
>>> I really hope it is. Best wishes and thank you all!
>>>
>>
>> Thank you very much, Doug!
>>
>
> Same here. Sadly, my talk wasn't admitted at ApacheCON
> (it seems very few were outside big data).
>
That's "unfortunate" - sorry.
> Doug, are we allowed to put that presentation into our Wiki?
> IMO, it covers the usual dos and donts very well.
>
Yes, I did the work necessary to enable you to put the work up on your
wiki. Credit to WANdisco/me.
> Also, is there some experience with strategies / suggestions
> like "put generic access first" and "put generic restrictions last"?
I've been meaning to write up some guidance. I'll try to find some time.
> Svn devs: the attachment is a presentation Doug had prepared for
>> explaining the Authz wilcard rules as implemented for WANdisco a couple of
>> years ago, which they have been using with svn 1.9.x, and which is a little
>> different from the 'authzperf' version that we have recently merged to
>> trunk for 1.10.
>>
> The behavior in /trunk is almost identical to WD-code.
> There are two main differences:
>
> * /trunk now uses are specialized parser for authz.
> Some accidental features of the previously used
> config parser are no longer available. In particular,
> sections may no longer be repeated and there is
> no support for value expansion.
>
Just checking: can there be 2 sections of:
[/]
* = r
[/]
accountA = rw
accountB = rw
Or is this now going to fail?
Can you say more about the "value expansion"?
> * An edge-case or two has been fixed concerning
> recursive access rights. Those are checked by new
> authz tests introduced in r1774890 and r1764337.
> Some of that may already be in the WD code.
We've gotten at least one fix - definitely!
> I suggested to Stefan2 that the one thing we're missing is clear
>> documentation of the new work, and to Doug that we might benefit from using
>> the content of his presentation as a starting point to create our own docs
>> for the new work.
>>
> Yes, a simple paragraph in the release notes will
> not do. Not sure though, when exactly I will find
> time and energy to write this.
>
> Doug is very keen that WD's version and our "official" version of wildcard
>> support should align in the long term, and in support of this, kindly
>> agreed to contribute this for us to use as we see fit.
>>
> Any feedback is greatly appreciated.
>
Again, sorry for the delay in replying. I don't get time to peruse the Dev
list all the time.
Ping me directly if you need a reply (doug.robinson@wandisco.com)!
Cheers.
Doug
--
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER
T +1 925 396 1125
*E* doug.robinson@wandisco.com
--
World Leader in Active Data Replication™
*Find out more wandisco.com <http://wandisco.com/>*
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE
PRIVILEGED
If this message was misdirected, WANdisco, Inc. and its subsidiaries,
("WANdisco") does not waive any confidentiality or privilege. If you are
not the intended recipient, please notify us immediately and destroy the
message without disclosing its contents to anyone. Any distribution, use or
copying of this email or the information it contains by other than an
intended recipient is unauthorized. The views and opinions expressed in
this email message are the author's own and may not reflect the views and
opinions of WANdisco, unless the author is authorized by WANdisco to
express such views or opinions on its behalf. All email sent to or from
this address is subject to electronic storage and review by WANdisco.
Although WANdisco operates anti-virus programs, it does not accept
responsibility for any damage whatsoever caused by viruses being passed.
Re: Subversion AuthZ Wildcards
Posted by Doug Robinson <do...@wandisco.com>.
Brane:
On Thu, Jun 1, 2017 at 7:36 PM, Branko Čibej <br...@apache.org> wrote:
> On 02.06.2017 00:11, Doug Robinson wrote:
> >> * /trunk now uses are specialized parser for authz.
> >> Some accidental features of the previously used
> >> config parser are no longer available. In particular,
> >> sections may no longer be repeated and there is
> >> no support for value expansion.
> >>
> > Just checking: can there be 2 sections of:
> >
> > [/]
> > * = r
> >
> > [/]
> > accountA = rw
> > accountB = rw
> >
> > Or is this now going to fail?
>
> This is now going to fail. People would have to write:
>
> [/]
> * = r
> accountA = rw
> accountB = rw
>
>
> The rationale for this restriction is this: if we allow the same section
> to appear multiple times, it becomes too hard to determine in which
> order the rules should be applied and which rules take precedence. This
> was not such an issue before when a section name (path) was always an
> exact match (although q.v. global vs. repository-specific rules, too).
> With wildcards, it's much easier to write multiple sections that match
> the same concrete path; so we must have a consistent way to determine
> which rule actually applies.
>
> Consider, supposing we allowed repeating sections:
>
> [:glob:/foo/*]
> $authenticated = r
>
> [/foo/bar]
> accountA = rw
>
> [:glob:/foo/*]
> accountA =
>
>
> When we look at /foo/bar in a repository as accountA, what should
> happen? Our current behavour is, IIRC, that the rule that was defined
> last wins ... but which is last in this case? There are two possible
> answers, which means there's too much room for confusion. Hence the
> restriction.
>
Makes perfect sense. Thank you!
> Can you say more about the "value expansion"?
>
> In Subversion config files you can write something like this:
>
> [DEFAULT]
> foo = bar
>
> [section]
> option = %(foo)s
>
>
> which will be equivalent to:
>
> [section]
> option = bar
>
>
> In other words, we support variable expansion similar to Python's
> ConfigParser module. Because we used to have the same parser for authz
> files as for config files, this misfeature was also supported in authz
> files. The new parser does not support variable expansion.
>
Great that was never documented! Ugh.
Thank you again - cheers!
Doug
--
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER
T +1 925 396 1125
*E* doug.robinson@wandisco.com
--
World Leader in Active Data Replication™
*Find out more wandisco.com <http://wandisco.com/>*
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE
PRIVILEGED
If this message was misdirected, WANdisco, Inc. and its subsidiaries,
("WANdisco") does not waive any confidentiality or privilege. If you are
not the intended recipient, please notify us immediately and destroy the
message without disclosing its contents to anyone. Any distribution, use or
copying of this email or the information it contains by other than an
intended recipient is unauthorized. The views and opinions expressed in
this email message are the author's own and may not reflect the views and
opinions of WANdisco, unless the author is authorized by WANdisco to
express such views or opinions on its behalf. All email sent to or from
this address is subject to electronic storage and review by WANdisco.
Although WANdisco operates anti-virus programs, it does not accept
responsibility for any damage whatsoever caused by viruses being passed.
Re: Subversion AuthZ Wildcards
Posted by Branko Čibej <br...@apache.org>.
On 02.06.2017 00:11, Doug Robinson wrote:
>> * /trunk now uses are specialized parser for authz.
>> Some accidental features of the previously used
>> config parser are no longer available. In particular,
>> sections may no longer be repeated and there is
>> no support for value expansion.
>>
> Just checking: can there be 2 sections of:
>
> [/]
> * = r
>
> [/]
> accountA = rw
> accountB = rw
>
> Or is this now going to fail?
This is now going to fail. People would have to write:
[/]
* = r
accountA = rw
accountB = rw
The rationale for this restriction is this: if we allow the same section
to appear multiple times, it becomes too hard to determine in which
order the rules should be applied and which rules take precedence. This
was not such an issue before when a section name (path) was always an
exact match (although q.v. global vs. repository-specific rules, too).
With wildcards, it's much easier to write multiple sections that match
the same concrete path; so we must have a consistent way to determine
which rule actually applies.
Consider, supposing we allowed repeating sections:
[:glob:/foo/*]
$authenticated = r
[/foo/bar]
accountA = rw
[:glob:/foo/*]
accountA =
When we look at /foo/bar in a repository as accountA, what should
happen? Our current behavour is, IIRC, that the rule that was defined
last wins ... but which is last in this case? There are two possible
answers, which means there's too much room for confusion. Hence the
restriction.
> Can you say more about the "value expansion"?
In Subversion config files you can write something like this:
[DEFAULT]
foo = bar
[section]
option = %(foo)s
which will be equivalent to:
[section]
option = bar
In other words, we support variable expansion similar to Pyhon's
ConfigParser module. Because we used to have the same parser for authz
files as for config files, this misfeature was also supported in authz
files. The new parser does not support variable expansion.
-- Brane