0

After successfully organizing a large number of repositories in a deep subdirectory tree for years, somewhere between Gitolite 3.6.6 and 3.6.11 for RHEL/Centos 7 I lost the ability to access repositories stored in subdirectories.

Attempts to fetch or push fail with a "Denied by fallthrough", while repositories in top level directories can be accessed successfully.

Gitolite config is as follows

@supergroup = spirald

@foogroup = spirald
@foogroup = johnny

repo gitolite-admin
    RW+     =   @supergroup

repo testing
    RW+     =   @all

repo foo/bar/baz
    RW+     =   @foogroup

repo footest
    RW+     =   @foogroup

Gitolite logs as follows:

2020-04-22.11:04:24     27731   ssh     ARGV=spirald       SOC=git-upload-pack 'foo/bar/baz'      FROM=111.222.333.444
2020-04-22.11:04:24     27731   die     R any foo/bar/baz spirald DENIED by fallthru<<newline>>(or you mis-spelled the reponame)

ssh info shows the following

hello spirald, this is git@aserver running gitolite3 3.6.11-1.el7 on git 1.8.3.1

 R W    footest
 R W    gitolite-admin
 R W    testing

In the git account, gitolite access -s foo/bar/baz spirald W any returns

FATAL: this should not happen! W any foo/bar/baz spirald DENIED by fallthru at /usr/share/gitolite3/commands/access line 101, <DATA> line 1.

While: gitolite access -s footest spirald W any returns

legend:
    d => skipped deny rule due to ref unknown or 'any',
    r => skipped due to refex not matching,
    p => skipped due to perm (W, +, etc) not matching,
    D => explicitly denied,
    A => explicitly allowed,
    F => fallthru; access denied for normal refs, allowed for VREFs

  A        gitolite.conf:23         RW+     =   @foogroup

refs/.*

gitolite list-* commands show the repo and the memberships properly

Does anyone have insight into this issue or some kind of workaround that doesn't involve changing a whole lot of URLs?

spirald
  • 39
  • 5

1 Answers1

3

Solved!

In the git account on my server I used

gitolite setup --hooks-only

Looks like a recent gitolite release caused an issue if this was never done with a repo. I just dropped an existing repo into the repositories dir managed by gitolite so I never did this initially.

spirald
  • 39
  • 5
  • I had this problem with the `gitolite-admin` and `testing` repositories on gitolite 3.6.12-1 installed from apt on Debian Bullseye. Running `sudo -u gitolite gitolite setup --hooks-only` sorted it out. Kudos for figuring it out, I was scratching my head for quite a while before I found this post! Since I couldn't access the `gitolite-admin` repo, I couldn't set up any users or other repos... – Kitserve Jul 15 '23 at 10:27