Gitolite no respeta las reglas cuando se accede a través de httpd

Convencí a la oficina de que deberíamos mudarnos a Git. Como recién estamos comenzando, configuré un server de git usando plain git y https frente a él usando nginx. No usamos gitlab ni nada por el estilo, por ahora.

Una de las preguntas que recibí es si sería posible restringir el acceso a twigs específicas (especialmente el maestro) para nuevos colegas. Nos habría ahorrado muchos problemas en el pasado 🙂

Durante mi búsqueda de una solución, encontré la gitolita muy prometedora, así que la probé y configuré. Me puse de pie y corrí a través de la gitolita, así que empecé a profundizar en las reglas.

Sin embargo, no puedo entenderlos correctamente. Parece que la gitolita ignora el segundo control

Mi gitlolite-admin/conf/gitolite.conf ve así (tenía uno más complejo, pero mientras lo gitlolite-admin/conf/gitolite.conf al mínimo)

 @starters = auric # project groups @protected = master$ repo gitolite-admin RW+ = admin repo testing RW+ = @all repo playground R = @starters # allow read from protected - @protected = @starters # deny anything else RW+ = @starters # allow everything on other branches 

En los documentos, se especifica que puede rastrear la decisión de control de acceso .

salida de gitolite access -s playground auric de gitolite access -s playground auric es esto

acceso de tirón

 $ gitolite access -s playground auric R master 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 => denied due to fallthru (no rules matched) A gitolite.conf:14 R = @starters # allow read from protected refs/.* 

acceso de empuje

 $ gitolite access -s playground auric W master p gitolite.conf:14 R = @starters # allow read from protected D gitolite.conf:15 - @protected = @starters # deny anything else W refs/heads/master playground auric DENIED by refs/heads/master$ 

rebobinar el acceso de inserción

 $ gitolite access -s playground auric + master p gitolite.conf:14 R = @starters # allow read from protected D gitolite.conf:15 - @protected = @starters # deny anything else + refs/heads/master playground bert.van.dooren DENIED by refs/heads/master$ 

acceso de empuje en otra twig

 $ gitolite access -s playground bert.van.dooren W anyotherbranch p gitolite.conf:14 R = @starters # allow read from protected r gitolite.conf:15 - @protected = @starters # deny anything else A gitolite.conf:16 RW+ = @starters # allow everything on other branches refs/.* 

exactamente lo que esperaba que fuera. y de hecho, esto es lo que veo en ~/.gitolite/logs después de ejecutar estos commands ( ~/.gitolite/logs la date aquí):

 32205 cli gitolite access -s playground auric W master 32205 system,/home/git/gitolite/src/commands/access,-s,playground,auric,W,master 32205 system() failed,/home/git/gitolite/src/commands/access,-s,playground,auric,W,master,-> 256 

Sin embargo, cuando realmente empiezo a usar git y realizo un push (e incluso un push de rebobinado) a través de httpd, todos los commands están permitidos y veo esto en los loggings

 32196 http ARGV=auric SOC=git-receive-pack 'playground.git' FROM=10.0.13.105 32196 pre_git playground auric W any refs/.* 32196 system,git,http-backend 32196 END 

como si solo se hiciera el check 1 pero el check 2 nunca llega.

¿Qué extraño aquí?

editar Estoy usando gitolite3. Sé que hay algunas respuestas acerca de cómo agregar la regla R master = @starters pero luego gitolite me da la advertencia de que esa regla no tiene ningún sentido. Es ignorado

Las notas de gitolite dev mencionan el paso pregit como la línea de logging que aparece cuando la primera verificación de acceso tiene éxito (es decir, antes de git-upload-pack o git-receive-pack ).

Sin embargo, el paso de update no aparece en el logging: es el paso que aparece cuando la segunda verificación de acceso tiene éxito (es decir, cuando el gancho de update decide permitir el envío).

Eso significa que el enlace de actualización para ese repos podría no estar en su lugar (enlace simbólico en cada carpeta de annotations de repo al guión de actualización de gitolite).
Se gitolite setup se encarga de esos enlaces.

En realidad, los comentarios de OP Auric a continuación :

Mientras que el gancho de update estaba en su lugar y realmente gitolite setup , lo hice con otro usuario .

Como no fcgiwrap configurar fcgiwrap para que se ejecutara con otro usuario, tuve que asegurarme de que gitolite se instaló bajo el usuario git , pero fue ejecutable utilizando el usuario www-data .
bindfs para este propósito.
Pero desde que gitolite setup en el usuario git , el enlace de update se /home/git/.gitolite/... a /home/git/.gitolite/... en lugar de /opt/gitolite/.gitolite/...
Así que ahora volví a ejecutar la configuration con /opt/gitolite como $HOME para que el enlace simbólico sea correcto.