web-dev-qa-db-fra.com

Comment faire un dépôt git en lecture seule?

Certains référentiels git sont accessibles à distance via SSH et je souhaite rendre certains d'entre eux en lecture seule pour éviter d'autres envois. Certaines personnes ont des télécommandes pointant vers ces dépôts.

Ces référentiels nus ont été initialisés --shared=group. Par conséquent, la définition d'autorisations de fichier sur 660 pour tous les fichiers est-elle suffisante pour autoriser l'accès SSH, mais interdire les écritures? Ou y a-t-il un moyen plus facile?

À votre santé.

gitreadonly
47
Steve Folly

Il y a plus d'une façon possible de faire cela.

  • Si vos utilisateurs ont chacun un compte Shell (peut-être limité) et que chacun d'entre eux accède aux référentiels git via leur propre compte, vous pouvez utiliser les autorisations filesystem pour contrôler l'accès SSH aux référentiels git. Sous Unix, il s’agirait d’autorisations d’écriture sur répertoires, éventuellement avec l’aide de la création d’un groupe et d’autorisations spécifiques pour un groupe (avec "ID groupe collant" défini).

  • Pousser nécessite que git-receive-pack soit dans $ PATH de l'utilisateur et qu'il soit exécutable pour eux ... bien que je ne sois pas sûr de la faisabilité de cette approche.

  • Vous pouvez utiliser update ou pre-receive hook pour contrôler l'accès au référentiel, par exemple en utilisant update-paranoid example hook à partir de contrib/hooks dans les sources git.

  • Avec un plus grand nombre d’utilisateurs, il serait préférable d’utiliser un outil pour gérer l’accès aux dépôts git, comme Gitosis (en Python, nécessite setuptools) ou Gitolite (en Perl).

  • Pour un accès en lecture seule, vous pouvez configurer le démon git pour fournir un accès anonyme en lecture seule (et non authentifié) via le protocole git://, au lieu d’un accès via le protocole SSH. 

    Voir la documentation pour la variable url.<base>.insteadOf config pour trouver un moyen de faciliter la transition du protocole SSH vers le protocole GIT.

Voir aussi le chapitre 4. " Git sur le serveur " de Pro Git book de Scott Chacon (sous licence CC-BY-NC-SA).

42
Jakub Narębski
chmod -R a-w /path/to/repo.git
9
Pat Notz

Un hook pre-receive qui imprime simplement un message informatif et qui sort avec un statut différent de zéro fait le travail. 

En supposant que vous mettiez des informations significatives dans votre message, cela réduit également le nombre de requêtes d'utilisateurs frustrés qui demandent pourquoi ils ne peuvent pas pousser:

#!/bin/bash
echo "=================================================="
echo "This repository is no longer available for pushes."
echo "Please visit blah blah yadda yadda ...."
echo "=================================================="
exit 1

N'oubliez pas de définir l'autorisation d'exécution du script et de vous assurer que le nom du bon utilisateur et/ou du bon groupe lui appartient, sinon il ne s'exécutera pas et ne donnera aucun avertissement.

8
Dale Anderson

Puisque git s'appuie principalement sur le système de fichiers pour le contrôle d'accès, cela fonctionnera. Notez que dans vos autorisations, le monde n'a pas accès au fichier, mais l'utilisateur et le groupe ont un accès en lecture/écriture. Si vous voulez être lisible par tout le monde, vos permissions devraient être 0444.

Vous pouvez effectuer un contrôle plus fin en définissant les autorisations de mise en pension sur 0664, où l'utilisateur est nobody et le groupe est quelque chose comme gitdevs. Ensuite, seules les personnes du groupe gitdevs pourront écrire dans le référentiel, mais le monde pourra en lire.

SuiviVoici un lien qui couvre les différentes manières de partager votre référentiel et les couvertures qui viennent, et les fonctionnalités de contrôle d'accès.

3
jheddings

Inspiré par ce commentaire :

  1. Mettez à jour votre fichier hooks/pre-receive avec le contenu suivant:

    #!/bin/sh

echo "Closed for all pushes" ; exit 1

De cette manière, tous les utilisateurs essayant de transmettre des modifications à ce référentiel recevront le message ci-dessus et la diffusion sera rejetée.

2
Per Lundberg

Si vous avez également besoin d’un contrôle d’accès, consultez gitosis . Assez facile à configurer et vous pouvez utiliser un simple script pour contrôler qui peut faire quoi.

1
Makis

Comme je ne suis qu'un utilisateur de notre GitLab (et que je ne voulais pas déranger les administrateurs dans un premier temps), j'ai cherché un autre moyen et en ai trouvé un:

  • Ouvrez l’interface Web GitLab et accédez au référentiel que vous souhaitez définir en lecture seule.
  • Choisissez Paramètres> Référentiel
  • Développer Branches protégées
  • Ajouter la branche principale et définir Autorisé à fusionner et Autorisé à appuyer à Personne
  • Si la branche principale est déjà protégée, vous pouvez définir ces valeurs dans la liste ci-dessous.
0
Nicolas

Le protocole git est une autre possibilité, mais le démon git doit être en cours d'exécution.

0
Ikke

Récemment, j'ai limité l'accès au chemin "/repo.git/git-receive-pack" pour obtenir le résultat suivant: le référentiel est en lecture-écriture pour certains utilisateurs et en lecture seule pour d'autres. Dans httpd config, cela ressemble à ceci:

    <Location /repo.git/>
            Require group developers developers-ro
    </Location>

    <Location /repo.git/git-receive-pack>
            Require group developers
    </Location>
0
keypress