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/05/01 14:20:16 UTC
Re: wildcard authz docs question
Daniel:
On Mon, Apr 17, 2017 at 21:13 Daniel Shahaf <d....@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.
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.
Doug
>
> > The problem is that the authz callback does not provide
> > enough context information to make that distinction.
> > We might extend the interface in the future - allowing
> > to restrict rules to exclusively match files or dirs only.
>
> Are you referring to svn_repos_authz_check_access()? [which doesn't
> have an svn_fs_t handle or the information to open one]
>
> > But making that backward compatible adds quite a bit
> > of complexity that I don't want to pile on there in 1.10.
>
> I don't understand this sentence at all. Why do we need to be backwards
> compatible (this is a new feature), and why is being back compat in
> this case necessarily expensive?
>
> Moreover, implementation considerations aside, there is still the
> question of what the documentation should say about this situation.
>
> Cheers,
>
> Daniel
>
--
*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: wildcard authz docs question
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Thu, May 04, 2017 at 13:26:30 +0200:
> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <d....@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 cribbed the syntax from zsh and rsync, which both define a "***" token
in their glob expressions.
(In zsh, *** is like ** but recurses into symlinks-to-directories as
well. In rsync, *** is similar to ** but can match zero path components
in the construct "foo/***)
Re: wildcard authz docs question
Posted by Doug Robinson <do...@wandisco.com>.
Johan:
On Thu, May 4, 2017 at 7:26 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <d....@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.
>
>
> 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).
>
> --
> Johan
>
--
*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: wildcard authz docs question
Posted by Doug Robinson <do...@wandisco.com>.
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 <br...@apache.org> wrote:
> On 05.05.2017 11:09, Johan Corveleyn wrote:
> > On Fri, May 5, 2017 at 12:49 AM, Doug Robinson
> > <do...@wandisco.com> wrote:
> >> Johan:
> >>
> >> (sorry for the empty message - dwim failed)
> >>
> >> On Thu, May 4, 2017 at 7:26 AM, Johan Corveleyn <jc...@gmail.com>
> wrote:
> >>> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <d....@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@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: wildcard authz docs question
Posted by Branko Čibej <br...@apache.org>.
On 05.05.2017 11:09, Johan Corveleyn wrote:
> On Fri, May 5, 2017 at 12:49 AM, Doug Robinson
> <do...@wandisco.com> wrote:
>> Johan:
>>
>> (sorry for the empty message - dwim failed)
>>
>> On Thu, May 4, 2017 at 7:26 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>>> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <d....@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
Re: wildcard authz docs question
Posted by Doug Robinson <do...@wandisco.com>.
Johan, et. al.:
Solid discussion - thank you. As I said, I'll keep a watch as things
progress...
Cheers.
Doug
On Wed, May 10, 2017 at 5:37 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Wed, May 10, 2017 at 5:40 PM, Doug Robinson
> <do...@wandisco.com> wrote:
> >
> > Johan:
> >
> > Sorry for my sporadic replies... bin a bit hectic here.
> >
> > Reply buried deep below.
> >
> > On Fri, May 5, 2017 at 5:09 AM, Johan Corveleyn <jc...@gmail.com>
> wrote:
> >>
> >> On Fri, May 5, 2017 at 12:49 AM, Doug Robinson
> >> <do...@wandisco.com> wrote:
> >> >
> >> > Johan:
> >> >
> >> > (sorry for the empty message - dwim failed)
> >> >
> >> > On Thu, May 4, 2017 at 7:26 AM, Johan Corveleyn <jc...@gmail.com>
> wrote:
> >> >>
> >> >> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <
> d.s@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.
> >>
> >> Now, getting back to your use case: "reserving a namespace for future
> >> use" (i.e. for now we don't know whether "iota" will ever be a file or
> >> a directory, but in any case we don't want anyone to put anything
> >> there). To me it sounds like a very special use case. It seems to be
> >> something specific for authorization syntaxes, but much less
> >> applicable to searching existing filesystems (like glob patterns for
> >> shells or tools like FishEye). So maybe it's not such a good idea to
> >> look at those tools for inspiration anyway :-).
> >>
> >> Doug: do you think this is a common use case? Do other authorization
> >> systems offer this functionality in an easily configurable manner? I
> >> accept this is a valid use case, but it's not one that I would think
> >> of using (wearing my hat of svn admin) -- I focus on authorization of
> >> the existing files / directories.
> >
> >
> > It's a very common use case. Think of it in terms of allocating all
> release
> > branches to the release team. Or all Quality Assurance tags to the QA
> team.
>
> OK
>
> >>
> >> Come to think of it: if reserving a namespace for future use, and
> >> "/iota" doesn't exist yet, can't you just block the name "/iota"
> >> without glob pattern? It doesn't exist anyway, so if you'd like to
> >> create some subtree under it, you first have to create /iota, right?
> >
> >
> > There's 2 problems with this:
> >
> > 1. You're not trying to block the name "/iota", you're giving out privs
> to the
> > right team for creating (and nobody else).
> >
> > 2. The "**" operator is very special in that it does a "direct match" of
> all
> > at or below. That "direct match", in terms of wildcards, means that
> there
> > is no "recursing upwards" to find a parent rule. It's matched
> immediately.
> >
> > Consider multiple repositories in an organization (perhaps they have code
> > that cannot go to vendors with which they share some repos so they cannot
> > keep all of their projects within a single repo - or similar use case).
> A global
> > policy would have identical rules for all repositories. They can't know
> when
> > or if some subset of the repositories have the specific artifact or not.
> > It would be nice/handy/convenient if a single rule could do the
> reservation
> > rather than a pair.
>
> Okay, thanks for clarifying. It's all starting to make sense to me now :-).
>
> So the "reserve namespace" usecase is common and important, and it
> sounds very sensible to want to do this with a single rule. And the
> "**" matching is better at doing this than the "/iota" rule. Got it.
>
> >> Now, in the end, I don't want this issue to be blocked forever :-). I
> >> think in practice the confusion will be minimal, because either the
> >> administrator knows what kind of item "iota" is (a file or a
> >> directory), or the item doesn't exist yet and he'll be doing the
> >> "reserve namespace" use case. So for me it's fine if "/iota/**"
> >> effectively matches both the "directory iota and its subtree" and "the
> >> file iota". As long as it's documented that way then :-).
> >
> >
> > My document does that since that is the way that the branched
> > implementation for SVN 1.8 and 1.9 works today.
>
> Great.
>
> >> If Daniel insists, I'm fine with using "/***" as well, if we want to
> >> have this special "reserve namespace" meaning.
> >
> >
> > If so then we'll need to make sure to document the required changes to
> > our user's who are using the feature now. It's not a big deal but will
> be
> > critical when our users upgrade to SVN 1.10. So I'll continue to watch
> > this space carefully.
>
> As Daniel said, he doesn't insist :-) ... I misinterpreted that. And
> given that "/**" is already in use by your users as well as others
> that have already used the branched implementation
> (branches/authzperf), I see no reason to make things more difficult
> for little to no gain. So let's leave things like that.
>
> Thanks for your patience in discussing this.
>
> --
> Johan
>
--
*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: wildcard authz docs question
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, May 10, 2017 at 11:37 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Wed, May 10, 2017 at 5:40 PM, Doug Robinson
> <do...@wandisco.com> wrote:
>>
>> Johan:
>>
>> Sorry for my sporadic replies... bin a bit hectic here.
>>
>> Reply buried deep below.
>>
>> On Fri, May 5, 2017 at 5:09 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>>>
>>> On Fri, May 5, 2017 at 12:49 AM, Doug Robinson
>>> <do...@wandisco.com> wrote:
>>> >
>>> > Johan:
>>> >
>>> > (sorry for the empty message - dwim failed)
>>> >
>>> > On Thu, May 4, 2017 at 7:26 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>>> >>
>>> >> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <d....@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.
>>>
>>> Now, getting back to your use case: "reserving a namespace for future
>>> use" (i.e. for now we don't know whether "iota" will ever be a file or
>>> a directory, but in any case we don't want anyone to put anything
>>> there). To me it sounds like a very special use case. It seems to be
>>> something specific for authorization syntaxes, but much less
>>> applicable to searching existing filesystems (like glob patterns for
>>> shells or tools like FishEye). So maybe it's not such a good idea to
>>> look at those tools for inspiration anyway :-).
>>>
>>> Doug: do you think this is a common use case? Do other authorization
>>> systems offer this functionality in an easily configurable manner? I
>>> accept this is a valid use case, but it's not one that I would think
>>> of using (wearing my hat of svn admin) -- I focus on authorization of
>>> the existing files / directories.
>>
>>
>> It's a very common use case. Think of it in terms of allocating all release
>> branches to the release team. Or all Quality Assurance tags to the QA team.
>
> OK
>
>>>
>>> Come to think of it: if reserving a namespace for future use, and
>>> "/iota" doesn't exist yet, can't you just block the name "/iota"
>>> without glob pattern? It doesn't exist anyway, so if you'd like to
>>> create some subtree under it, you first have to create /iota, right?
>>
>>
>> There's 2 problems with this:
>>
>> 1. You're not trying to block the name "/iota", you're giving out privs to the
>> right team for creating (and nobody else).
>>
>> 2. The "**" operator is very special in that it does a "direct match" of all
>> at or below. That "direct match", in terms of wildcards, means that there
>> is no "recursing upwards" to find a parent rule. It's matched immediately.
>>
>> Consider multiple repositories in an organization (perhaps they have code
>> that cannot go to vendors with which they share some repos so they cannot
>> keep all of their projects within a single repo - or similar use case). A global
>> policy would have identical rules for all repositories. They can't know when
>> or if some subset of the repositories have the specific artifact or not.
>> It would be nice/handy/convenient if a single rule could do the reservation
>> rather than a pair.
>
> Okay, thanks for clarifying. It's all starting to make sense to me now :-).
>
> So the "reserve namespace" usecase is common and important, and it
> sounds very sensible to want to do this with a single rule. And the
> "**" matching is better at doing this than the "/iota" rule. Got it.
>
>>> Now, in the end, I don't want this issue to be blocked forever :-). I
>>> think in practice the confusion will be minimal, because either the
>>> administrator knows what kind of item "iota" is (a file or a
>>> directory), or the item doesn't exist yet and he'll be doing the
>>> "reserve namespace" use case. So for me it's fine if "/iota/**"
>>> effectively matches both the "directory iota and its subtree" and "the
>>> file iota". As long as it's documented that way then :-).
>>
>>
>> My document does that since that is the way that the branched
>> implementation for SVN 1.8 and 1.9 works today.
>
> Great.
>
>>> If Daniel insists, I'm fine with using "/***" as well, if we want to
>>> have this special "reserve namespace" meaning.
>>
>>
>> If so then we'll need to make sure to document the required changes to
>> our user's who are using the feature now. It's not a big deal but will be
>> critical when our users upgrade to SVN 1.10. So I'll continue to watch
>> this space carefully.
>
> As Daniel said, he doesn't insist :-) ... I misinterpreted that. And
> given that "/**" is already in use by your users as well as others
> that have already used the branched implementation
> (branches/authzperf), I see no reason to make things more difficult
> for little to no gain. So let's leave things like that.
>
> Thanks for your patience in discussing this.
On rereading this ... didn't want to give the impression that I'm
concluding this discussion on my own.
The above is just my opinion.
--
Johan
Re: wildcard authz docs question
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, May 10, 2017 at 5:40 PM, Doug Robinson
<do...@wandisco.com> wrote:
>
> Johan:
>
> Sorry for my sporadic replies... bin a bit hectic here.
>
> Reply buried deep below.
>
> On Fri, May 5, 2017 at 5:09 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>>
>> On Fri, May 5, 2017 at 12:49 AM, Doug Robinson
>> <do...@wandisco.com> wrote:
>> >
>> > Johan:
>> >
>> > (sorry for the empty message - dwim failed)
>> >
>> > On Thu, May 4, 2017 at 7:26 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>> >>
>> >> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <d....@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.
>>
>> Now, getting back to your use case: "reserving a namespace for future
>> use" (i.e. for now we don't know whether "iota" will ever be a file or
>> a directory, but in any case we don't want anyone to put anything
>> there). To me it sounds like a very special use case. It seems to be
>> something specific for authorization syntaxes, but much less
>> applicable to searching existing filesystems (like glob patterns for
>> shells or tools like FishEye). So maybe it's not such a good idea to
>> look at those tools for inspiration anyway :-).
>>
>> Doug: do you think this is a common use case? Do other authorization
>> systems offer this functionality in an easily configurable manner? I
>> accept this is a valid use case, but it's not one that I would think
>> of using (wearing my hat of svn admin) -- I focus on authorization of
>> the existing files / directories.
>
>
> It's a very common use case. Think of it in terms of allocating all release
> branches to the release team. Or all Quality Assurance tags to the QA team.
OK
>>
>> Come to think of it: if reserving a namespace for future use, and
>> "/iota" doesn't exist yet, can't you just block the name "/iota"
>> without glob pattern? It doesn't exist anyway, so if you'd like to
>> create some subtree under it, you first have to create /iota, right?
>
>
> There's 2 problems with this:
>
> 1. You're not trying to block the name "/iota", you're giving out privs to the
> right team for creating (and nobody else).
>
> 2. The "**" operator is very special in that it does a "direct match" of all
> at or below. That "direct match", in terms of wildcards, means that there
> is no "recursing upwards" to find a parent rule. It's matched immediately.
>
> Consider multiple repositories in an organization (perhaps they have code
> that cannot go to vendors with which they share some repos so they cannot
> keep all of their projects within a single repo - or similar use case). A global
> policy would have identical rules for all repositories. They can't know when
> or if some subset of the repositories have the specific artifact or not.
> It would be nice/handy/convenient if a single rule could do the reservation
> rather than a pair.
Okay, thanks for clarifying. It's all starting to make sense to me now :-).
So the "reserve namespace" usecase is common and important, and it
sounds very sensible to want to do this with a single rule. And the
"**" matching is better at doing this than the "/iota" rule. Got it.
>> Now, in the end, I don't want this issue to be blocked forever :-). I
>> think in practice the confusion will be minimal, because either the
>> administrator knows what kind of item "iota" is (a file or a
>> directory), or the item doesn't exist yet and he'll be doing the
>> "reserve namespace" use case. So for me it's fine if "/iota/**"
>> effectively matches both the "directory iota and its subtree" and "the
>> file iota". As long as it's documented that way then :-).
>
>
> My document does that since that is the way that the branched
> implementation for SVN 1.8 and 1.9 works today.
Great.
>> If Daniel insists, I'm fine with using "/***" as well, if we want to
>> have this special "reserve namespace" meaning.
>
>
> If so then we'll need to make sure to document the required changes to
> our user's who are using the feature now. It's not a big deal but will be
> critical when our users upgrade to SVN 1.10. So I'll continue to watch
> this space carefully.
As Daniel said, he doesn't insist :-) ... I misinterpreted that. And
given that "/**" is already in use by your users as well as others
that have already used the branched implementation
(branches/authzperf), I see no reason to make things more difficult
for little to no gain. So let's leave things like that.
Thanks for your patience in discussing this.
--
Johan
Re: wildcard authz docs question
Posted by Doug Robinson <do...@wandisco.com>.
Johan:
Sorry for my sporadic replies... bin a bit hectic here.
Reply buried deep below.
On Fri, May 5, 2017 at 5:09 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Fri, May 5, 2017 at 12:49 AM, Doug Robinson
> <do...@wandisco.com> wrote:
> >
> > Johan:
> >
> > (sorry for the empty message - dwim failed)
> >
> > On Thu, May 4, 2017 at 7:26 AM, Johan Corveleyn <jc...@gmail.com>
> wrote:
> >>
> >> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <d....@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.
>
> Now, getting back to your use case: "reserving a namespace for future
> use" (i.e. for now we don't know whether "iota" will ever be a file or
> a directory, but in any case we don't want anyone to put anything
> there). To me it sounds like a very special use case. It seems to be
> something specific for authorization syntaxes, but much less
> applicable to searching existing filesystems (like glob patterns for
> shells or tools like FishEye). So maybe it's not such a good idea to
> look at those tools for inspiration anyway :-).
>
> Doug: do you think this is a common use case? Do other authorization
> systems offer this functionality in an easily configurable manner? I
> accept this is a valid use case, but it's not one that I would think
> of using (wearing my hat of svn admin) -- I focus on authorization of
> the existing files / directories.
>
It's a very common use case. Think of it in terms of allocating all release
branches to the release team. Or all Quality Assurance tags to the QA team.
> Come to think of it: if reserving a namespace for future use, and
> "/iota" doesn't exist yet, can't you just block the name "/iota"
> without glob pattern? It doesn't exist anyway, so if you'd like to
> create some subtree under it, you first have to create /iota, right?
>
There's 2 problems with this:
1. You're not trying to block the name "/iota", you're giving out privs to
the
right team for creating (and nobody else).
2. The "**" operator is very special in that it does a "direct match" of all
at or below. That "direct match", in terms of wildcards, means that there
is no "recursing upwards" to find a parent rule. It's matched immediately.
Consider multiple repositories in an organization (perhaps they have code
that cannot go to vendors with which they share some repos so they cannot
keep all of their projects within a single repo - or similar use case). A
global
policy would have identical rules for all repositories. They can't know
when
or if some subset of the repositories have the specific artifact or not.
It would be nice/handy/convenient if a single rule could do the reservation
rather than a pair.
Now, in the end, I don't want this issue to be blocked forever :-). I
> think in practice the confusion will be minimal, because either the
> administrator knows what kind of item "iota" is (a file or a
> directory), or the item doesn't exist yet and he'll be doing the
> "reserve namespace" use case. So for me it's fine if "/iota/**"
> effectively matches both the "directory iota and its subtree" and "the
> file iota". As long as it's documented that way then :-).
>
My document does that since that is the way that the branched
implementation for SVN 1.8 and 1.9 works today.
If Daniel insists, I'm fine with using "/***" as well, if we want to
> have this special "reserve namespace" meaning.
>
If so then we'll need to make sure to document the required changes to
our user's who are using the feature now. It's not a big deal but will be
critical when our users upgrade to SVN 1.10. So I'll continue to watch
this space carefully.
Thank you.
Doug
[1] Steps to reproduce with ant (you'll need ant and java):
> * Create a file build.xml with this content:
> [[[
> <project name="test" default="test" basedir=".">
> <target name="test">
> <echo>Concatenating:</echo>
> <concat>
> <fileset dir="." includes="test/**,dir/**"/>
> </concat>
> </target>
> </project>
> ]]]
>
> * Create a file "test" with some content, and a directory "dir" with
> another file with other content below it.
>
> * Run "ant". You'll see that the content of "test" is not catted.
>
> * If you change the includes pattern to "**/test/**,dir/**", the file
> is effectively catted
>
> --
> Johan
>
--
*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: wildcard authz docs question
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Fri, May 05, 2017 at 11:09:33 +0200:
> Come to think of it: if reserving a namespace for future use, and
> "/iota" doesn't exist yet, can't you just block the name "/iota"
> without glob pattern? It doesn't exist anyway, so if you'd like to
> create some subtree under it, you first have to create /iota, right?
>
> Now, in the end, I don't want this issue to be blocked forever :-). I
> think in practice the confusion will be minimal, because either the
> administrator knows what kind of item "iota" is (a file or a
> directory), or the item doesn't exist yet and he'll be doing the
> "reserve namespace" use case. So for me it's fine if "/iota/**"
> effectively matches both the "directory iota and its subtree" and "the
> file iota". As long as it's documented that way then :-).
>
> If Daniel insists, I'm fine with using "/***" as well, if we want to
> have this special "reserve namespace" meaning.
I hope I'm not coming across as "insisting", Johan. I certainly didn't
intend to.
Regarding "reserve a namespace", I agree with you that "[/trunk/iota]
*=" appears to serve that purpose. Let's wait to hear from Doug.
Cheers,
Daniel
Re: wildcard authz docs question
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, May 5, 2017 at 12:49 AM, Doug Robinson
<do...@wandisco.com> wrote:
>
> Johan:
>
> (sorry for the empty message - dwim failed)
>
> On Thu, May 4, 2017 at 7:26 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>>
>> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <d....@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.
Now, getting back to your use case: "reserving a namespace for future
use" (i.e. for now we don't know whether "iota" will ever be a file or
a directory, but in any case we don't want anyone to put anything
there). To me it sounds like a very special use case. It seems to be
something specific for authorization syntaxes, but much less
applicable to searching existing filesystems (like glob patterns for
shells or tools like FishEye). So maybe it's not such a good idea to
look at those tools for inspiration anyway :-).
Doug: do you think this is a common use case? Do other authorization
systems offer this functionality in an easily configurable manner? I
accept this is a valid use case, but it's not one that I would think
of using (wearing my hat of svn admin) -- I focus on authorization of
the existing files / directories.
Come to think of it: if reserving a namespace for future use, and
"/iota" doesn't exist yet, can't you just block the name "/iota"
without glob pattern? It doesn't exist anyway, so if you'd like to
create some subtree under it, you first have to create /iota, right?
Now, in the end, I don't want this issue to be blocked forever :-). I
think in practice the confusion will be minimal, because either the
administrator knows what kind of item "iota" is (a file or a
directory), or the item doesn't exist yet and he'll be doing the
"reserve namespace" use case. So for me it's fine if "/iota/**"
effectively matches both the "directory iota and its subtree" and "the
file iota". As long as it's documented that way then :-).
If Daniel insists, I'm fine with using "/***" as well, if we want to
have this special "reserve namespace" meaning.
[1] Steps to reproduce with ant (you'll need ant and java):
* Create a file build.xml with this content:
[[[
<project name="test" default="test" basedir=".">
<target name="test">
<echo>Concatenating:</echo>
<concat>
<fileset dir="." includes="test/**,dir/**"/>
</concat>
</target>
</project>
]]]
* Create a file "test" with some content, and a directory "dir" with
another file with other content below it.
* Run "ant". You'll see that the content of "test" is not catted.
* If you change the includes pattern to "**/test/**,dir/**", the file
is effectively catted
--
Johan
Re: wildcard authz docs question
Posted by Doug Robinson <do...@wandisco.com>.
Johan:
(sorry for the empty message - dwim failed)
On Thu, May 4, 2017 at 7:26 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <d....@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.
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: wildcard authz docs question
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <d....@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.
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).
--
Johan
Re: wildcard authz docs question
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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....@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....@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.
Re: wildcard authz docs question
Posted by Doug Robinson <do...@wandisco.com>.
Daniel:
On Mon, May 1, 2017 at 2:05 PM, Daniel Shahaf <d....@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....@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@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: wildcard authz docs question
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Doug Robinson wrote on Mon, May 01, 2017 at 14:20:16 +0000:
> Daniel:
>
> On Mon, Apr 17, 2017 at 21:13 Daniel Shahaf <d....@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.
> 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.
Cheers,
Daniel