2015-04-24 4 views
3

J'ai GITOLITE sur mon serveur et je veux configurer l'accès à mon dépôt. Je veux restreindre l'accès à certaines branches pour certains utilisateurs. J'essaie beaucoup de variantes comment configurer le fichier gitolite.conf et je n'ai pas trouvé de solution pour restreindre l'accès à certaines branches.Gitolite restreindre l'accès à la succursale

1)

@developers1 = user1 
@developers2 = user2 

repo dbatest 
    RW+ = @developers1 
    R test = @developers2 
    - test = @developers2 
    RW+ = @developers2 

Lorsque utilisateur2 commande exécutée: git push origin test: racler réussir dans le journal gitolite j'avais ces lignes:

http ARGV=user2 SOC=git-receive-pack 'dbatest' FROM=10.65.184.239 
6453 pre_git dbatest user2 W any refs/.* 
6453 system,git,http-backend 
6453 END 

2)

@developers1 = user1 
@developers2 = user2 

repo dbatest 
    RW+ = @developers1 
    - test = @developers2 
    RW+ = @developers2 

Lorsque USER2 exécuté commande: git push origin test: push réussi dans le journal gitolite j'avais ces lignes:

http ARGV=user2 SOC=git-receive-pack 'dbatest' FROM=10.65.184.239 
6457 pre_git dbatest user2 W any refs/.* 
6457  system,git,http-backend 
6457 END 

3)

@developers1 = user1 
@developers2 = user2 

repo dbatest 
    RW+ = @developers1 
    R test = @developers2 
    - test = @developers2 
    RW+ = @developers2 
    option deny-rules = 1 

Lorsque utilisateur2 commande exécutée: git push origin test: pousser refusé et il a vu ce message:

fatal: remote error: FATAL: W any dbatest user2 DENIED by refs/heads/test 
(or you mis-spelled the reponame) 

Et gitolite J'ai eu ceci:

8161 http ARGV=user2 SOC=git-receive-pack 'dbatest' FROM=10.65.184.239 
8161 die W any dbatest user2 DENIED by refs/heads/test<<newline>>(or you mis-spelled the reponame) 

Ça a l'air bien, mais quand il essayait de pousser quelque chose dans la branche principale, il avait ce genre de mission.

J'ai essayé de mélanger ces lignes dans mon fichier de configuration gitolite mais elles n'ont pas fonctionné pour moi.

Je serai heureux si quelqu'un peut m'aider avec cela. Je veux restreindre l'accès en écriture à certaines branches pour certains développeurs. Je ne peux pas créer de référentiel supplémentaire Je dois utiliser la politique de restriction sur un référentiel principal.

Grand Merci!

Répondre

2

Si je regarde la official documentation:

repo foo bar 

    RW+      = alice @teamleads 
    - master    = dilbert @devteam 
    - refs/tags/v[0-9] = dilbert @devteam 
    RW+ dev/    = dilbert @devteam 
    RW      = dilbert @devteam 
    R      = @managers 

dilbert et l'équipe a dev ces restrictions

they can do anything to branches whose names start with "dev/" 
**they can create or fast-forward push, but not rewind or delete, any branch except `master`** 

Donc ceci semble juste:

- test = @developers2 
    RW+ = @developers2 

Cependant gitolite a deux contrôles:

  • un quand l'arbitre est inconnu (auquel cas - test est ignoré),
  • un pour l'arbitre est connu.

Dans votre cas, le ref (test) doit être connu et la règle de refus s'applique.

Vous pouvez déboguer plus en traçant la logique de vos règles spécifiques:

gitolite access -s dbatest user2 W test 

Le OP Sufelfay confirme in the comments que il fonctionne avec 3.5.3, 3.6.x pas.

+0

Merci pour votre réponse. Je restaure mon fichier de configuration à partir de la deuxième version ci-dessus. Et exécutez la commande cette commande. Ma sortie est: D => explicitement refusé, D gitolite.conf: 15 - test = @ developers2 Comment je comprends que cela devrait fonctionner correctement, mais malheureusement, il n'est pas – Sufelfay

+0

@Sufelfay à propos, quelle version de gitolite sont vous utilisez? – VonC

+0

Ma version est v 3.6.2. – Sufelfay

0

Comme Sufelfay l'a dit dans les commentaires à l'autre poste, c'est un bug dans les versions récentes de Gitolite.

La vérification d'accès est divisée en deux phases. Au cours de la phase inital, le ref est inconnu et Gitolite est censé ignorer toutes les règles se référant aux références.

En fait, cependant, il applique toutes les règles mais ignore la spécification ref. Ainsi ...

- test = @developers2 

... est évaluée comme ...

- = @developers2 

... au cours de la première phase. Pour aggraver les choses, l'erreur indique la toute dernière règle qui a été traitée. Cette règle peut ne pas être liée.

Pour contourner ce problème, vous pouvez ajouter une règle d'accès pour any avant que les règles REFUS

RW any = @developers2 
- test = @developers2 
...