Organisation de l'accès multi-utilisateur sur le serveur GIT

Lors de l'installation et de la configuration d'un serveur Git, la question de l'organisation de l'accès pour plusieurs utilisateurs à plusieurs projets se pose. J'ai mené des recherches et trouvé une solution qui répond à toutes mes exigences : simple, sécurisée et fiable.

Mes souhaits sont les suivants :

• chaque utilisateur se connecte avec son propre compte
• plusieurs utilisateurs peuvent travailler sur un même projet
• un même utilisateur peut travailler sur plusieurs projets
• chaque utilisateur a accès uniquement aux projets sur lesquels il travaille
• il doit être possible de se connecter via la ligne de commande, et pas seulement par une interface web

Il serait également bien de :

• fournir des droits en lecture seule pour les superviseurs
• administrer facilement les droits d'accès des utilisateurs dans Git

Aperçu des options d'accès au serveur GIT

Tout d'abord, il faut savoir ce qu'il y a à choisir, d'où une brève présentation des protocoles Git.

• ssh - un compte utilisateur spécifiquement créé est utilisé pour accéder au serveur.
  • Il est étrange que Git ne recommande pas l'utilisation d'un seul compte pour accéder à tous les dépôts. Cela ne correspond pas à mes exigences.
  • Il est possible d'utiliser plusieurs comptes, mais comment restreindre l'accès d'un utilisateur à seulement certains répertoires ?
    • Limiter l'accès au répertoire personnel n'est pas adéquat, car il est difficile d'organiser l'accès en écriture pour d'autres utilisateurs.
    • L'utilisation de liens symboliques depuis le répertoire personnel est également difficile car Git ne les interprète pas comme des liens.
    • Restreindre l'accès à l'interpréteur, c'est possible, mais il n'y a pas de garantie que cela fonctionnera toujours.
      • On peut même connecter un interpréteur de commandes spécifique pour ces utilisateurs, mais,
        • d'une part, c'est déjà une solution complexe,
        • et d'autre part, cela peut être contourné.

  Mais peut-être que ce n'est pas un problème que l'utilisateur puisse exécuter n'importe quelle commande ?... En tout cas, on ne peut pas exclure ce moyen, il suffit de trouver comment l'utiliser. Revenons à cette méthode plus tard, pour l'instant, examinons brièvement les autres alternatives, peut-être qu'il y a quelque chose de plus simple.

• Le protocole git local peut être utilisé en conjonction avec sshfs, permettant plusieurs utilisateurs, mais en essence, c'est la même chose que le cas précédent.
• http — en lecture seule
• git — en lecture seule
• https — difficile à installer, nécessite un logiciel supplémentaire, quelque chose. le panneau de contrôle Pour organiser l'accès des utilisateurs… cela semble réalisable, mais c'est un peu compliqué.

Utilisation du protocole ssh pour organiser l'accès multi-utilisateurs au serveur Git

Retour au protocole ssh.

Étant donné que l'accès ssh est utilisé pour git, il est nécessaire d'assurer la sécurité des données du serveur. L'utilisateur qui se connecte via ssh utilise son propre identifiant sur le serveur Linux, donc il peut se connecter via un client ssh et accéder à la ligne de commande du serveur.
Il n'y a pas de protection complète contre l'accès ainsi obtenu.

Mais pour l'utilisateur, les fichiers Linux ne doivent pas être intéressants. Les informations significatives ne sont stockées que dans le dépôt git. Par conséquent, l'accès via la ligne de commande peut ne pas être limité, mais les moyens Linux devraient interdire à l'utilisateur de voir les projets, sauf ceux auxquels il participe.
Il est évident d'utiliser le système de droits d'accès Linux.

Comme déjà mentionné, il est possible d'utiliser un seul compte pour l'accès ssh. Cette configuration est peu sûre pour plusieurs utilisateurs, bien que cette méthode soit incluse dans la liste des options recommandées par git.

Pour réaliser les exigences énoncées au début de l'article, la structure de répertoires suivante est créée avec des droits et des propriétaires attribués :

1) répertoires des projets

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
…
où
dir1, dir2, dir3 — répertoires des projets : projet 1, projet 2, projet 3.

proj1:proj1, proj2:proj2, proj3:proj3 — utilisateurs Linux spécialement créés, qui sont désignés comme propriétaires des répertoires des projets correspondants.

Les droits sur tous les répertoires sont fixés à 0770 — accès complet pour le propriétaire et son groupe et interdiction totale pour tous les autres.

2) comptes des développeurs

Développeur 1 : dev1:dev1,proj1,proj2
Développeur 2 : dev2:dev2,proj2,proj3

Le point clé est que des groupes supplémentaires sont attribués aux développeurs pour le système utilisateur propriétaire du projet correspondant. Cela est fait par l'administrateur du serveur Linux en une seule commande.

Dans cet exemple, « Développeur 1 » travaille sur les projets proj1 et proj2, tandis que « Développeur 2 » travaille sur les projets proj2 et proj3.

Si l'un des Développeurs se connecte via ssh en ligne de commande, ses droits seront insuffisants même pour afficher le contenu des répertoires des projets auxquels il ne participe pas. Il ne peut pas changer cela lui-même.

Étant donné que la base de ce principe est la sécurité fondamentale des droits Linux, ce schéma est fiable. De plus, il est très facile à administrer.

Passons à la pratique.

Création de dépôts Git sur un serveur Linux

Vérification en cours.

[root@server ~]# cd /var/
[root@server var]# useradd gitowner
[root@server var]# mkdir gitservertest
[root@server var]# chown gitowner:gitowner gitservertest
[root@server var]# adduser proj1
[root@server var]# adduser proj2
[root@server var]# adduser proj3
[root@server var]# adduser dev1
[root@server var]# adduser dev2
[root@server var]# passwd dev1
[root@server var]# passwd dev2

fatigué de taper à la main...

[root@server gitservertest]# sed "s/ /n/g" <<< "proj1 proj2 proj3" | while read u; do mkdir $u; chown $u:$u $u; chmod 0770 $u; done

[root@server gitservertest]# usermod -aG proj1 dev1
[root@server gitservertest]# usermod -aG proj2 dev1
[root@server gitservertest]# usermod -aG proj2 dev2
[root@server gitservertest]# usermod -aG proj3 dev2

Nous nous assurons qu'il est impossible d'accéder aux dépôts d'autres depuis la ligne de commande, même pour voir leur contenu.

[dev1@server ~]$ cd /var/gitservertest/proj3
-bash: cd: /var/gitservertest/proj3: Permission denied
[dev1@server ~]$ ls /var/gitservertest/proj3
ls: impossible d'ouvrir le répertoire /var/gitservertest/proj3: Permission denied

Collaboration dans Git entre plusieurs développeurs sur un même projet

Une seule question demeure : si un développeur ajoute un nouveau fichier, les autres développeurs ne peuvent pas le modifier, car il en est le propriétaire (par exemple, dev1), et non l'utilisateur-propriétaire du projet (par exemple, proj1). Étant donné que nous avons un dépôt serveur, il est essentiel de comprendre comment est structurée le répertoire « .git » et si de nouveaux fichiers sont créés.

Création d'un dépôt Git local et push vers le serveur Git

Passons à la machine cliente.

Microsoft Windows [Version 6.1.7601]
(c) Microsoft Corporation, 2009. Tous droits réservés.

C:gittest>git init .
Dépôt Git vide initialisé dans C:/gittest/.git/

C:gittest>echo "test dev1 to proj2" > test1.txt

C:gittest>git add .

C:gittest>git status
Sur la branche master
Aucun commit encore
Modifications à valider :
  (utilisez "git rm --cached ..." pour désélectionner)
        nouveau fichier :   test1.txt

C:gittest>git commit -am "nouveau fichier de test ajouté"
[master (root-commit) a7ac614] nouveau fichier de test ajouté
 1 fichier modifié, 1 insertion(+)
 mode de création 100644 test1.txt
 
C:gittest>git remote add origin "ssh://dev1@10.1.1.11/var/gitservertest/proj2"

C:gittest>git push origin master
dev1:dev1@10.1.1.11's password:
Comptage des objets : 3, fait.
Écriture des objets : 100% (3/3), 243 octets | 243.00 KiB/s, fait.
Total 3 (delta 0), réutilisé 0 (delta 0)
Pour ssh://10.1.1.11/var/gitservertest/proj2
 * [nouvelle branche]      master -> master

C:gittest>

En même temps, de nouveaux fichiers sont créés sur le serveur, et ils appartiennent à l'utilisateur qui a effectué le push.

[dev1@server proj2]$ tree
.
├── 1.txt
├── branches
├── config
├── description
├── HEAD
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── prepare-commit-msg.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   └── update.sample
├── info
│   └── exclude
├── objects
│   ├── 75
│   │   └── dcd269e04852ce2f683b9eb41ecd6030c8c841
│   ├── a7
│   │   └── ac6148611e69b9a074f59a80f356e1e0c8be67
│   ├── f0
│   │   └── 82ea1186a491cd063925d0c2c4f1c056e32ac3
│   ├── info
│   └── pack
└── refs
    ├── heads
    │   └── master
    └── tags

12 répertoires, 18 fichiers
[dev1@server proj2]$ ls -l objects/75/dcd269e04852ce2f683b9eb41ecd6030c8c841
-r--r--r--. 1 dev1 dev1 54 Jun 20 14:34 objects/75/dcd269e04852ce2f683b9eb41ecd6030c8c841
[dev1@server proj2]$

Lors du téléchargement des modifications vers le serveur, des fichiers et des répertoires supplémentaires sont créés, et leur propriétaire est effectivement l'utilisateur qui effectue le téléchargement. Mais alors, le groupe de ces fichiers et répertoires correspond également au groupe principal de cet utilisateur, c'est-à-dire, le groupe dev1 pour l'utilisateur dev1 et le groupe dev2 pour l'utilisateur dev2 (changer le groupe principal de l'utilisateur développeur ne sera pas utile, car comment alors travailler sur plusieurs projets?). Dans ce cas, l'utilisateur dev2 ne pourra pas modifier les fichiers créés par l'utilisateur dev1, ce qui peut nuire à la fonctionnalité.

Linux chown — changement de propriétaire de fichier par un utilisateur ordinaire

Le propriétaire du fichier ne peut pas modifier son appartenance. Mais il peut changer le groupe du fichier qui lui appartient, et alors ce fichier peut être accessible à d'autres utilisateurs qui se trouvent dans ce même groupe. C'est exactement ce dont nous avons besoin.

Utilisation de Git hook

Le répertoire de travail pour hook est le répertoire racine du projet. hook est un fichier exécutable qui s'exécute sous l'utilisateur qui effectue le push. En tenant compte de cela, nous pouvons réaliser ce qui est prévu.

[dev1@server proj2]$ mv hooks/post-update{.sample,}
[dev1@server proj2]$ sed -i '2,$ s/^/#/' hooks/post-update
[dev1@server proj2]$ cat <<> hooks/post-update

ou simplement

vi hooks/post-update

Revenons sur la machine cliente.

C:gittest>echo "dev1 3rd line" >> test1.txt

C:gittest>git commit -am "3rd from dev1, testing server hook"
[master b045e22] 3rd from dev1, testing server hook
 1 fichier modifié, 1 insertion(+)

C:gittest>git push origin master
dev1:dev1@10.1.1.11's password:
   d22c66e..b045e22  master -> master

Sur le serveur Git, vérifions après le commit le fonctionnement du script hook post-update.

[dev1@server proj2]$ find . ! -group proj2

— vide, tout va bien.

Connexion du deuxième développeur dans Git

Simulons le travail du deuxième développeur.

Sur le client

C:gittest>git remote remove origin

C:gittest>git remote add origin "ssh://dev2@10.1.1.11/var/gitservertest/proj2"

C:gittest>echo "!!! dev2 added this" >> test1.txt

C:gittest>echo "!!! dev2 wrote" > test2.txt

C:gittest>git add test2.txt

C:gittest>git commit -am "dev2 added to test1 and created test2"
[master 55d49a6] dev2 added to test1 and created test2
 2 fichiers modifiés, 2 insertions(+)
 mode de création 100644 test2.txt

C:gittest>git push origin master
dev2@10.1.1.11's password:
   b045e22..55d49a6  master -> master

Et en même temps, sur le serveur…

[dev1@server proj2]$ find . ! -group proj2

— encore vide, tout fonctionne.

Suppression d'un projet Git et chargement d'un projet depuis le serveur Git

Eh bien, nous pouvons encore une fois nous assurer que tous les changements sont sauvegardés.

C:gittest>rd /S /Q .
Le processus ne peut pas accéder au fichier car ce fichier est occupé par un autre processus.

— pour supprimer un projet Git, nous nettoyons simplement le répertoire complètement. Acceptons l'erreur générée, car il est impossible de supprimer le répertoire actuel avec cette commande, mais ce comportement est précisément ce dont nous avons besoin.

C:gittest>dir
 Contenu du dossier C:gittest

21.06.2019  08:43              .
21.06.2019  08:43              ..

C:gittest>git clone ssh://dev2@10.1.1.11/var/gitservertest/proj2
Clonage dans 'proj2'...
dev2@10.1.1.11's password:

C:gittest>cd proj2

C:gittestproj2>dir
 Contenu du dossier C:gittestproj2

21.06.2019  08:46              .
21.06.2019  08:46              ..
21.06.2019  08:46               114 test1.txt
21.06.2019  08:46                19 test2.txt
C:gittestproj2>type test1.txt
"test dev1 to proj2"
"dev1 added some omre"
"dev1 3rd line"
"!!! dev2 added this"

C:gittestproj2>type test2.txt
"!!! dev2 wrote"

Séparation des accès dans Git

Assurons-nous maintenant que même via Git, le deuxième développeur ne peut pas accéder au projet Proj1, sur lequel il ne travaille pas.

C:gittestproj2>git remote remove origin

C:gittestproj2>git remote add origin "ssh://dev2@10.1.1.11/var/gitservertest/proj1"

C:gittestproj2>git push origin master
dev2@10.1.1.11's password:
fatal: '/var/gitservertest/proj1' ne semble pas être un dépôt git
fatal: Impossible de lire depuis le dépôt distant.

Veuillez vous assurer que vous disposez des droits d'accès corrects
et que le dépôt existe.

Maintenant, nous donnons accès

[root@server ~]# usermod -aG proj1 dev2

et après cela, tout fonctionne.

C:gittestproj2>git push origin master
dev2@10.1.1.11's password:
Pour ssh://10.1.1.11/var/gitservertest/proj1
 * [nouvelle branche]      master -> master

Informations supplémentaires

De plus, s'il y a un problème avec les droits par défaut lors de la création de fichiers et de répertoires, dans CentOS, on peut utiliser la commande

setfacl -Rd -m o::5 -m g::7 /var/gitservertest

Vous pouvez également trouver de petites choses utiles dans l'article :

• comment construire un arbre de répertoires en Linux
• comment, dans sed, passer une plage d'adresses d'une certaine ligne jusqu'à la fin du fichier, c'est-à-dire effectuer une substitution dans sed dans toutes les lignes sauf la première ligne
• Comment, dans Linux find, inverser la condition de recherche
• comment, dans le shell Linux, passer plusieurs lignes à une boucle via une ligne unique
• comment, dans bash, échapper des guillemets simples
• comment, dans la ligne de commande Windows, supprimer un répertoire avec tout son contenu
• Comment, avec bash mv, renommer un fichier sans le réécrire

Merci pour votre attention.

Source : habr.com