[Cryptech Tech] Some poblems with the repo access

Rob Austein sra at hactrn.net
Thu Feb 6 01:32:10 UTC 2014 

gitolite's "wild repository" mechanism (the hack that allows
authorized uses to create new repositories without needing full admin
rights to the entire gitolite system)  is a little strange.  It's
part of the permission system, but built around the concept of "roles"
instead of specific users.

The current permissions for wild repositories are:

    C   = @all
    RW+ = CREATOR
    RW  = WRITERS
    R   = READERS
    R   = @all

"@all" is a built-in user group meaning "all authorized users".   At
some point one or more references to @all may need to change to @core,
but as all authorized users are currently also people who would be in
@core, I haven't separated those.

Translation of the rules:

- Any authorized user can create a new repository

- Whichever user created the repository has full rights (read, write,
  and other operations like delete)

- The creator has the ability to give write access to any other
  authorized user ("WRITERS"), using the "perms" command, eg:

  $ ssh git at cryptech.is perms myrepo + WRITERS randy at psg.com

- The creator also has the ability to grant read access to any other
  authorized user ("READERS"), but as it's currently set up there's no
  point in doing this since I hard configured it to grant read access
  to anybody in core (@all, at the moment).

The gitolite documention claims that the normal way of creating a
repository like this is just to clone it.  Yes, you clone a
repository that doesn't exist to create it.

OK, with that as background, to the specific points in Joachim's
message:

> I can clone the testing repo with:
> 
> <quote>
> #> git clone git at cryptech.is:testing.git
> </quote>
> 
> But when I try to push a commit back to origin I get permission problems:
> 
> <quote>
> #> git push
> FATAL: W any testing joachim at secworks.se DENIED by fallthru
> (or you mis-spelled the reponame)
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> and the repository exists.
> </quote>
> 
> And if we check the status for the repo it shows that I only have 'R'
> access:
> 
> <quote>
> hello joachim at secworks.se, this is git at cryptech running gitolite3
> v3.5.2-0-g926bd5f on git 1.8.5.2
> 
>  R   C	[a-zA-Z0-9].*
>  R  	gitolite-admin
>  R  	testing
> <quote>

All of this is consistent with me having created the "testing"
repository (by cloning it) and not having thought to grant write
access to it to anybody else.  I think.

> Also, I've tried to create repos, but this also seems not to work (as I
> thought it should work:
> 
> <quote>
> ssh git at cryptech.is create test2
> Initialized empty Git repository in /usr/local/git/repositories/test2.git/
> 'batch' mode started, waiting for input (run with '-h' for details).
> Please hit Ctrl-C if you did not intend to do this.
> 
> IntegrityError: UNIQUE constraint failed: repository.id, repository.name
> </quote>
> 
> Testing with another name:
> <quote>
> ssh git at cryptech.is create verydifferentreponame
> Initialized empty Git repository in
> /usr/local/git/repositories/verydifferentreponame.git/
> 'batch' mode started, waiting for input (run with '-h' for details).
> Please hit Ctrl-C if you did not intend to do this.
> 
> IntegrityError: UNIQUE constraint failed: repository.id, repository.name
> </quote>
> 
> Google does not find an obvious solution for Gitolite.

i have no idea what this is about.   I suspect you'll get the same
error if you try creation-via-cloning, but it might be worth the
experiment.

> But the repos seems to be created anyway, so now we do have the repos
> test2 and verydifferentreponame.
> 
> <quote>
> hello joachim at secworks.se, this is git at cryptech running gitolite3
> v3.5.2-0-g926bd5f on git 1.8.5.2
> 
>  R   C	[a-zA-Z0-9].*
>  R  	gitolite-admin
>  R W	test2
>  R  	testing
>  R W	verydifferentreponame
> </quote>

Oh, goodie. So the error is some bit of post-processing (involving
SQL?!?).  Dunno, will have to research.

> I can clone these new repos. But when I try to push to test2 I get
> another issue:
> 
> <quote>
> #> git push
> Counting objects: 3, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (2/2), done.
> Writing objects: 100% (3/3), 314 bytes | 0 bytes/s, done.
> Total 3 (delta 0), reused 0 (delta 0)
> remote: ***
> remote: *** Improperly signed commit, not allowed:
> 8e2e374e291b5634c70e0eda6df136b14ba095b0 N -- checked but no further result
> remote: ***
> remote: FATAL: VREF/gpg-check: helper program exit status 256
> remote: error: hook declined to update refs/heads/master
> To git at cryptech.is:test2
>  ! [remote rejected] master -> master (hook declined)
> error: failed to push some refs to 'git at cryptech.is:test2'
> </quote>

That one is deliberate, and is because of the feature that this group
asked me to add: you cannot push commits to these repositories unless
they are signed by an authorized PGP key.  The current authorized PGP
keys are:

    pub   2048R/2DC6FF82 2006-03-08 [expires: 2014-11-17]
    uid                  Rob Austein <sra at hactrn.net>
    uid                  Rob Austein <sra at isc.org>
    uid                  Rob Austein <Rob_Austein at isc.org>
    sub   2048R/BF27AC3B 2006-03-08 [expires: 2014-11-17]

    pub   2048R/B83A02ED 2006-03-09 [expires: 2015-01-10]
    uid                  Randy Bush <randy at psg.com>
    uid                  [jpeg image of size 10407]
    sub   2048R/F0F6969F 2006-03-09 [expires: 2015-01-14]

    pub   4096R/23291265 2010-05-07
    uid                  Linus Nordberg <linus at nordberg.se>
    uid                  Linus Nordberg <linus at nordu.net>
    uid                  Linus Nordberg <linus at torproject.org>
    uid                  [jpeg image of size 2906]
    sub   4096R/153E576C 2013-04-23 [expires: 2014-04-23]

    pub   4096R/2422EC8D 2014-02-02 [expires: 2019-02-01]
    uid                  Joachim Strombergson <joachim at strombergson.com>
    uid                  Joachim Strombergson <joachim at secworks.se>
    sub   4096R/9D8F0EEB 2014-02-02 [expires: 2019-02-01]

> Finally a minor issue. I get "PTY allocation request failed on channel
> 0" when talking to gitolite over ssh:
> 
> <quote>
> ssh git at cryptech.is
> PTY allocation request failed on channel 0
> hello joachim at secworks.se, this is git at cryptech running gitolite3
> v3.5.2-0-g926bd5f on git 1.8.5.2
> 
>  R   C	[a-zA-Z0-9].*
>  R  	gitolite-admin
>  R W	test2
>  R  	testing
>  R W	verydifferentreponame
> Connection to cryptech.is closed.
> </quote>
> 
> The problem seems to be related to different version of ssh:
> https://stackoverflow.com/questions/10330678/gitolite-pty-allocation-request-failed-on-channel-0
> 
> Diabling pseudo-tty allocation in ssh makes the warning go away:
> 
> <quote>
> ssh -T git at cryptech.is
> hello joachim at secworks.se, this is git at cryptech running gitolite3
> v3.5.2-0-g926bd5f on git 1.8.5.2
> 
>  R   C	[a-zA-Z0-9].*
>  R  	gitolite-admin
>  R W	test2
>  R  	testing
>  R W	verydifferentreponame
> </quote>

Sigh.

More information about the Tech mailing list