Subversion AuthZ Wildcards

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Subversion AuthZ Wildcards

Doug Robinson
Folks:

"Julian said Stefan said this could be useful."  :-)

I really hope it is.  Best wishes and thank you all!

Doug
--
DOUGLAS B. ROBINSON SENIOR PRODUCT MANAGER




Learn how WANdisco Fusion solves Hadoop data protection and scalability challenges

Listed on the London Stock Exchange: WAND

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 e-mail or the information it contains by other than an intended recipient is unauthorized.  The views and opinions expressed in this e-mail 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.


SubversionWildcards.pptx (157K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion AuthZ Wildcards

Julian Foad-5
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!

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.

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.

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.

- Julian
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion AuthZ Wildcards

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

Doug, are we allowed to put that presentation into our Wiki?
IMO, it covers the usual dos and donts very well.

Also, is there some experience with strategies / suggestions
like "put generic access first" and "put generic restrictions last"?

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

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

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

-- Stefan^2.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion AuthZ Wildcards

Doug Robinson
Stefan:

[sorry for the delay]

On Thu, May 18, 2017 at 9:38 AM, Stefan Fuhrmann <[hidden email]> wrote:
On <a href="tel:27.02.2017%2017" value="+12702201717" target="_blank">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 ([hidden email])!

Cheers.

Doug
--
DOUGLAS B ROBINSON SENIOR PRODUCT MANAGER

World Leader in Active Data Replication™
Find out more 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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion AuthZ Wildcards

Branko Čibej
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion AuthZ Wildcards

Doug Robinson
Brane:

On Thu, Jun 1, 2017 at 7:36 PM, Branko Čibej <[hidden email]> 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

World Leader in Active Data Replication™
Find out more 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.

Loading...