Brane:
Right! And this is likely why the AuthZ implementation today for
"/**" governs both the "file" and "directory" since it can't know.
Given this, I'd like to keep the current behavior (that's in the branch
for 1.8 and 1.9) as it "works".
Thank you.
Doug
On Fri, May 5, 2017 at 5:22 AM, Branko Čibej <brane_at_apache.org> wrote:
> On 05.05.2017 11:09, Johan Corveleyn wrote:
> > On Fri, May 5, 2017 at 12:49 AM, Doug Robinson
> > <doug.robinson_at_wandisco.com> wrote:
> >> Johan:
> >>
> >> (sorry for the empty message - dwim failed)
> >>
> >> On Thu, May 4, 2017 at 7:26 AM, Johan Corveleyn <jcorvel_at_gmail.com>
> wrote:
> >>> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name>
> wrote:
> >>>> Doug Robinson wrote on Wed, May 03, 2017 at 15:54:50 -0400:
> >>> ...
> >>>>> 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?
> >>> Hmm, /*** doesn't look like something I'd remember easily, if I wanted
> >>> to use that feature as an svn admin.
> >>>
> >>> I have only followed this discussion from a distance. If I understand
> >>> correctly the remaining point is whether or not /iota/** would match
> >>> with the file /iota or not. Speaking purely from my own intuition, I
> >>> would say "no". I feel this pattern is intended to apply to the
> >>> _subtree_ below iota, including iota itself (which is thus implied to
> >>> be a directory, because we're talking about subtrees). In practice I
> >>> think the admin configuring this rule will know whether iota is ever
> >>> intended to be a file or a directory. A rule like that to me always
> >>> implies that "the guy who configured it" expects iota to be a
> >>> directory (why else would he put a "subtree rule" for it).
> >>>
> >>> TBH, I also don't really see the use case of "I want this rule to
> >>> apply to the _namespace_ iota, i.e. to the file iota (if it's a file)
> >>> and to directory iota and its subtree (if it's a directory)". In
> >>> context, you always know whether it's meant to be a file or a
> >>> directory.
> >>
> >> The use case is exactly that some administrator wants to reserve
> >> the namespace. They do not want some sly person to create a file
> >> where they will, at some point in the future, create a directory. It
> will
> >> be sad that we can't have a simple way to make this reservation, but,
> >> as I noted above, short of the current "[:glob:/iota/**]" doing the job
> it
> >> will take 2 stanzas.
> >>
> >>> Maybe we should just follow what most other implementations do?
> >>> I've done a quick check in Atlassian FishEye / Crucible (searching for
> >>> files). There /iota/** does not match file /iota (but it does match
> >>> directory /iota).
> >>
> >> The FishEye reference I found does not have a "**" operator - just a "*"
> >> operator (https://confluence.atlassian.com/jiracoreserver073/search-
> syntax-for-text-fields-861257223.html).
> >>
> >> For all cases where a tool has a "*" operator this is semantically going
> >> to "not match" this use case since the "*" operator that has been
> >> implemented in SVN (at least so far) does not span past a single
> >> directory entry.
> > Ah. No, I'm referring to this syntax in FishEye:
> > https://confluence.atlassian.com/fisheye/pattern-matching-
> guide-298976797.html
> >
> > Unfortunately the document does not specify the cases we're interested
> > in here. But I've tested them on our own FishEye instance :-). In this
> > case "/dir/**" does return /dir, but "/file/**" does not return /file.
> > But okay, it's just one example.
> >
> > In the FishEye doc they say they're doing their pattern mathing "same
> > as the pattern matching in Apache Ant". So I've checked ant as well.
> > On this page:
> >
> > https://ant.apache.org/manual/dirtasks.html#patterns
> >
> > at the bottom of the table they say:
> > **/test/** - Matches all files that have a test element in their
> > path, including test as a filename.
> >
> > So I've done a little test in ant (see [1]): apparently "**/test/**"
> > will match the file test, but "/test/**" doesn't! Weird. Apparently
> > the same goes for FishEye, if I put "**/" at the beginning of the
> > pattern, it does match the file.
>
>
> Before we go too far down this rabbit hole of possible semantics, I'd
> like to remind you that in Subversion's authz implementation, the path
> matching happens before we know anything about the structure of the
> repository. Specifically, we don't know if a particular name in the
> pattern even exists in the repository and if it does, whether it's a
> file or a directory.
>
> So, any discussion about whether something should match a file or not is
> nice in theory, but a waste of time in practice. IMO there is absolutely
> no chance of the authz check actually looking at the repository to
> determine what kind of object we're looking at: not only would this
> require a significant change in the authz architecture, it would also
> slow authz checks down to probably an order of magnitude worse than they
> were _before_ the current rewrite. A non-starter.
>
> It would be a lot better to discuss if the current behaviour is sensible
> given what we know when the authz check occurs.
>
> -- Brane
>
--
*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.
Received on 2017-05-10 17:42:03 CEST