J'ai quelques dépôts git accessibles à distance par SSH et je veux faire en sorte que certains d'entre eux soient en lecture seule pour éviter d'autres poussées. Certaines personnes ont des remotes qui pointent vers ces dépôts.
Ces dépôts nus ont été initialisés --shared=group Est-ce que le fait de définir les autorisations de fichiers à 660 pour tous les fichiers est suffisant pour permettre l'accès SSH, mais interdire l'écriture ? Ou existe-t-il un moyen plus simple ?
A la vôtre.
Il y a plus d'une façon possible de le faire.
Si vos utilisateurs ont chacun un compte shell (peut-être limité), et que chacun d'entre eux accède aux dépôts git via son propre compte, vous pouvez utiliser permissions du système de fichiers pour contrôler l'accès SSH aux dépôts git. Sous Unix, il s'agirait des droits d'écriture sur répertoires Il est possible de créer un groupe et des autorisations spécifiques pour un groupe (avec l'option "sticky group ID").
La poussée exige git-receive-pack pour être dans $PATH de l'utilisateur, et être exécutable pour lui... bien que je ne sois pas sûr de la faisabilité de cette approche.
Vous pouvez utiliser update o pre-receive crochet pour effectuer un contrôle d'accès au référentiel, par exemple à l'aide de update-paranoid exemple de crochet de contrib/hooks dans les sources git.
Si le nombre d'utilisateurs est plus important, il est préférable d'utiliser un système de gestion de la qualité. 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 démon git pour fournir un accès anonyme (et non authentifié) en lecture seule par le biais de git:// au lieu de l'accès via le protocole SSH.
Voir la documentation pour url.<base>.insteadOf pour faciliter la transition de SSH au protocole GIT.
Voir également le chapitre 4. " Git sur le serveur " de Pro Git livre de Scott Chacon (licence CC-BY-NC-SA).
Il faut noter que pour les permissions du système de fichiers, vous pouvez utiliser chmod, comme le suggère Pat Notz.
Merci pour les idées (tout le monde). Inspiré par le hook de l'exemple update-paranoid, j'ai maintenant un hook dans mes dépôts qui fait simplement echo "Closed for all pushes" ; exit 1
@SteveFolly Si votre commentaire était une réponse, je voterais pour lui au lieu de la réponse acceptée. La vôtre est courte, précise et efficace.
Comme git s'appuie principalement sur le système de fichiers pour le contrôle d'accès, cela fonctionnera. Notez que dans vos permissions, 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 que le monde entier ait accès au fichier, vos permissions devraient être les suivantes 0444 .
Vous pouvez effectuer un contrôle plus fin en définissant les permissions du repo comme suit 0664 où l'utilisateur est nobody et le groupe est quelque chose comme gitdevs . Ensuite, seules les personnes de la gitdevs aura la possibilité d'écrire dans le dépôt, mais le monde entier pourra le lire.
Suivi Voici un lien qui couvre les différentes façons de partager votre repo et couvre les avantages et inconvénients et les fonctions de contrôle d'accès.
666 est le monde des fichiers lisibles et inscriptibles. 776 correspond à des fichiers lisibles, inscriptibles et exécutables par le monde et le groupe, et lisibles et inscriptibles par les autres utilisateurs. Je ne sais pas où vous avez trouvé les chiffres que vous recommandez, mais ils sont généralement dangereux.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
