Re: wildcard authz docs question

Daniel:

On Mon, May 1, 2017 at 2:05 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name>
wrote:

> Doug Robinson wrote on Mon, May 01, 2017 at 14:20:16 +0000:
> > On Mon, Apr 17, 2017 at 21:13 Daniel Shahaf <d.s_at_daniel.shahaf.name>
> wrote:
> > > Stefan Fuhrmann wrote on Mon, Apr 17, 2017 at 22:22:33 +0200:
> > > > On 15.03.2017 10:55, Daniel Shahaf wrote:
> > > > >>From the 1.10 draft release notes:
> > > > >
> > > > >>All wildcards apply to full path segments only, i.e. * never
> matches
> > > > >>/, except for the case where /**/ matches zero or more path
> segments.
> > > > >>For example, /*/**/* will match any path which contains at least
> > > > >>2 segments and is equivalent to /**/*/* as well as /*/*/**.
> > > > >Are «/*/**/*» «/**/*/*» «/*/*/**» really equivalent? I would have
> > > > >expected the first two to match any node except / and /'s immediate
> > > > >children, but I wouldn't expect the third form to match /trunk/iota
> > > > >where iota is a file, since the pattern has a trailing slash after
> the
> > > > >non-optional second component.
> > > > How do you know that /trunk/iota is a file?
> > >
> > > I was reviewing the API docs as a black box, i.e., from a user
> > > (repository admin) perspective, not from an implementation perspective.
> > >
> > > From that perspective, I would say that having a [/trunk/iota/**]
> > > stanza to apply to a /trunk/iota file violates the principle of least
> > > surprise.
> >
> >
> > From a very critical point of view I agree.
> >
> > However, the point of wildcards is to easily reserve a complete
> namespace.
>
> Sure, that's a valid use-case.
>
> I was envisioning that, if a [/trunk/iota/**] stanza were present, then
> an authz query for a /trunk/iota file would return either "No access" or
> a parse error. This would reserve the namespace, wouldn't it? Referring
> to your next paragraph, this logic would neither leak the contents of
> the file nor require multiple stanzas.
>

For an AuthZ check the answer is either Yes or No, not "parser error",
right?

And it really can't be a "parser error" (invalidating the AuthZ file
entirely) since
in some other revision that "file" could be a "directory". So either the
stanza
gets skipped as "not applicable" (and therefore not reserving the namespace)
or it gets entered as if the file were a directory and we're back to the
behavior
that I am expecting.

> > If we do not apply that stanza apply to the file means requiring 2
> stanzas
> > to cover the space entirely. That's both expensive and brittle (2X
> stanzas
> > and requires remembering to treat them in pairs - both when adding and
> when
> > removing).
> >
> > And I think the "surprise" will be very short-lived if at all.
> >
> > From a cost/benefit standpoint I think it is extremely positive.
>
> Well, if a common task requires two stanzas, then _of course_ we'll find
> an easier way for users to spell it. For example, we could invent some
> new "reserve prefix" stanza syntax, or pass to
> svn_repos_authz_check_access()
> the svn_node_kind_t of the path it checks access to, or any number of
> other solutions.
>
> In short: there might well be a design that meets both of our criteria:
> principle of least surprise _and_ namespace reservation.
>

Not seeing it - at least not yet. In Perl the RE needed to handle this
would
be one of the duals, e.g. "/trunk/iota(|/.*)" - the either/or with nothing
on the left
and "/.*" on the right. It really is a dual case. I know of no better
syntax. Since
we're working on this as a wildcard I don't see an alternative.

As I said, I think the surprise, if any (none if we document it well) will
be
very short-lived.

Cheers.

Doug

-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER
T +1 925 396 1125
*E* doug.robinson_at_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.