For my existing gitolite3-installation I want to add anonymous access, restricted to a certain number of repositories. Reading should be allowed for all these repositories, while write-operations should be protected.
For that I thought of passing a token with the push to the gitolite-repositories. A VREF recieves the token and checks if it's valid. If it is, the write-operation on the repository is allowed. The gitolite-conf should look like this:
repo @anonrepos
RW = @all
option deny-rules = 1
- VREF/MYTOKENREF = @all
(If the config contains errors, then I copied them wrong from the pc where they reside)
And for the vref I thought of:
#!/usr/bin/python3
token = input()
if is_valid(token): # TODO: define is_valid
exit(0) # Allow the push
else:
exit(1) # Deny it
So much for theory. When I try to push, I get an error because pythons input()
raises an EOFError. So I can't pass information to the vref via stdin and not via sys.argv
either.
Or am I wrong? Is there some way to pass an token to my vref, maybe via some git-command-line-trickery? Or is there some other way I can allow an anonymous push (literally everyone could push, so i need to protect these repositories) if I am sure the person behind it is legitimate? I was thinking about whitelisting the commit-id of the commit that is about to be pushed, but that isn't a flexible way to do it.
Note: The procedure for someone to push should be like his: That someone messages me that he wants to push to a repository, I create a token and send it to him and at last he pushes to the repository successfully using the supplied token.
Another approach is to define a group of user that you don't populate.
repo test-ldap-devel
RW+ = @devel
To determine if a user is in that devel group (and authorize to push), you write a program which, given a username, queries a user referential and returns a space-separated list of groups that the user is a member of.
Then put the full path to this program in an rc
variable called GROUPLIST_PGM
, like so:
GROUPLIST_PGM => '/home/git/bin/ldap-query-groups',
This is usually done with an LDAP referential in mind (as in this example), but you could use any other referential.
That could replace the notion of token which seems problematic to pass along.