Doug Robinson wrote on Wed, May 03, 2017 at 15:54:50 -0400:
> 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?
Wrong. An authz check can return an error. For example, `svnauthz
accessof` has exit code 2 when the authz file fails to parse.
> 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.
You are correct: it will not be a *parse* error since the grammar of
authz files does not depend on the contents of the repository. That
just means it will be a different kind of error — a semantic error — and
will occur at authz query time, not at authz file load time.
That would still break checkouts of /trunk, though, so it might be
better to just default /trunk/iota to "No access" and log a warning to
the server log. (Using, say, svn_repos_fs(repos)->warning().)
>
> > > 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.
Off the top of my head, we could have [/trunk/iota/***] and
[/trunk/iota/**] with different meanings (the former applies to
a /trunk/iota file, the latter doesn't). Does anyone else (besides Doug
and I) have ideas here?
Cheers,
Daniel
> As I said, I think the surprise, if any (none if we document it well)
> will be very short-lived.
Received on 2017-05-04 10:16:24 CEST