Gitolite tags matching in gitolite3

[Tom Robinson]

Hi all,

I've been working with milki for the past months now on a gitolite installation for my workplace! However, I appear to be experiencing an issue with tags matching not doing what I expect, and I was hoping I had simply overlooked how to do this correctly the documentation.

After reading the (admittedly older) documentation for gitolite 2 (http://gitolite.com/gitolite/g2/aac.html), I tried this on an instance of *gitolite 3*:

@tags_limited_repos = @my_repos @my_other_repos
repo @tags_limited_repos

RW+ refs/tags/v(.*) = @my_spiffy_group @my_other_spiffy_group
R refs/tags/v(.*) = my_user # my_user is also part of @rw_users
- refs/tags/v(.*) = @all
option deny-rules = 1

repo @my_repos
R = @ro_users
RW+ = @rw_users

I then tried to write any content to a repo in @my_repos as my_ro_user as a smoke test to see if the rule was working properly, including to master, and discovered every attempt denied as so:

FATAL: W any repos/test_repo my_user DENIED by refs/tags/v(.*)

This blocked every path, including writes to master. This also blocked all other members of @rw_users not in @my_spiffy_group and @my_other_spiffy_group from performing any reads and writes until I reverted the change.

I also tried rewriting the rule without the glom operator, like so:

RW+ refs/tags/v = @my_spiffy_group @my_other_spiffy_group
R refs/tags/v = my_user
- refs/tags/v = @all

And got:

FATAL: W any repos/test_repo my_user DENIED by refs/tags/v

When I remove these three lines entirely, my reads and writes to @my_repos proceed as normal.

This clearly is not working as I expect, and I suspect simple syntax may be to blame. I, however, have not been able to puzzle out quite what's going on here both from the docs and a quick look at the source.

Could someone please tell me where I went wrong here?

Best regards,
- Tom Robinson

[Sitaram Chamarty]

You seem to have misunderstood the need for (and the use of) the
'deny-rules' option.

Get rid of it.

Also, using a refex on an "R" perm line is useless.

[Tom Robinson]

Thanks, Sitaram. This was cleared up for me when I referred to Chapter 7 of Gitolite Essentials.

For the audience reading this, a section within the chapter covers this case explicitly. Since enabling deny-rules enables read checks, - includes read operations, and a refex is not checked on read (because vanilla Git doesn't provide the capability to do so), this would result in a deny for all reads matching my_user and @all. Oh, dear.

Apologies for the common "gotcha". The book is excellent, by the way. :)

- Tom Robinson

On Tuesday, April 22, 2014 3:53:53 AM UTC-7, Sitaram Chamarty wrote:
> You seem to have misunderstood the need for (and the use of) the
>
> 'deny-rules' option.
>
>
>
> Get rid of it.
>
>
>
> Also, using a refex on an "R" perm line is useless.
>
>
>
> On 04/22/2014 10:10 AM, Tom Robinson wrote:
>
> > Hi all,
>

*cut*

[Tom Robinson]

Coincidentally, while this has probably been considered before, would it be reasonable to throw a configuration error if a refex shows up in a read rule? It seems to me that such presence will always be cross-intent with what an author expects, and adding a check would prevent these surprises from happening. (I'm on the fence on whether this should require some other condition to raise an error, such as deny-rules = 1.)

That said, this can also be caught in testing (ie, as with milki's recently added Perl test cases). I'm just thinking along the lines of the Principle of Least Astonishment here.

- Tom

[Sitaram Chamarty]

On 04/23/2014 02:52 AM, Tom Robinson wrote:
> Thanks, Sitaram. This was cleared up for me when I referred to Chapter
> 7 of Gitolite Essentials.
>
> For the audience reading this, a section within the chapter covers
> this case explicitly. Since enabling deny-rules enables read checks, -
> includes read operations, and a refex is not checked on read (because
> vanilla Git doesn't provide the capability to do so), this would
> result in a deny for all reads matching my_user and @all. Oh, dear.
>
> Apologies for the common "gotcha". The book is excellent, by the way. :)

Thanks :-)

While I appreciate the compliment, I would not want anyone to think that
the book is *necessary* to use gitolite. That was never the intention,
and in any case the online docs -- by nature -- are more complete and
more current.

What the book does is provide a much more measured and gradual treatment
of the topics that are covered. With the online docs, there's this
feeling that people only read the parts they want, and it's difficult to
write with that in mind. With the book, I can *expect* people to read
more than just a few sentences and draw conclusions from them.

This specific instance is quite adequately covered in rules.html [1].

[1]: http://gitolite.com/gitolite/rules.html#deny-rules

[Sitaram Chamarty]

On 04/23/2014 04:49 AM, Tom Robinson wrote:
> Coincidentally, while this has probably been considered before, would
> it be reasonable to throw a configuration error if a refex shows up in
> a read rule? It seems to me that such presence will always be
> cross-intent with what an author expects, and adding a check would
> prevent these surprises from happening. (I'm on the fence on whether
> this should require some other condition to raise an error, such as
> deny-rules = 1.)

Good idea; thanks. It's not an "error" per se, but a sign of
misunderstanding, regardless of whether deny-rules is on or not.

Will do.