Organisation de l'accès multi-utilisateurs au serveur GIT

Lors de l'installation et de la configuration d'un serveur Git, la question se pose d'organiser l'accès de plusieurs utilisateurs à plusieurs projets. J'ai mené une étude sur le problème et trouvé une solution qui répond à toutes mes exigences: simple, sûre, fiable.

Mes souhaits sont les suivants:

• chaque utilisateur se connecte avec son propre compte
• plusieurs utilisateurs peuvent travailler sur un même projet
• le même utilisateur peut travailler sur plusieurs projets
• chaque utilisateur n'a accès qu'aux projets sur lesquels il travaille
• devrait être en mesure de se connecter via la ligne de commande, et pas seulement via une sorte d'interface Web

Ce serait aussi formidable:

• accorder des droits en lecture seule aux personnes détenant le contrôle
• administrer facilement les autorisations des utilisateurs dans Git

Présentation des options d'accès au serveur GIT

Tout d'abord, vous devez savoir quoi choisir, donc un bref aperçu des protocoles Git.

• ssh - un compte utilisateur spécialement créé est utilisé pour accéder au serveur.
  
  • il est étrange que Git n'exclue pas des recommandations l'utilisation d'un seul compte pour accéder à tous les référentiels. Cela ne correspond pas à mes exigences.
  • Vous pouvez utiliser plusieurs comptes, mais comment restreindre l'accès des utilisateurs à certains répertoires uniquement?
    
    
    • La fermeture du répertoire personnel ne convient pas, car il est difficile d'organiser l'accès en écriture pour les 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
    • Il est possible de restreindre l'accès à l'interprète, mais rien ne garantit que cela fonctionnera toujours
      
      
      • Vous pouvez même connecter votre propre interpréteur de commandes pour ces utilisateurs, mais,
        
        
        • premièrement, c'est déjà une sorte de décision difficile,
        • et en 2, cela peut être contourné.
  
  Mais peut-être que ce n'est pas un problème que l'utilisateur sera en mesure d'exécuter des commandes? .. En général, cette méthode ne peut pas être exclue si vous trouvez comment l'utiliser. Nous reviendrons sur cette méthode plus tard, mais pour l'instant, considérons brièvement les autres alternatives, peut-être que quelque chose y sera plus facile.
  
• Le protocole local git peut être utilisé en combinaison avec sshfs, plusieurs utilisateurs peuvent être utilisés, mais en substance, c'est le même que le cas précédent
• http - lecture seule
• git est en lecture seule
• https - il est difficile à installer, vous avez besoin de logiciels supplémentaires, d'une sorte de panneau de contrôle pour organiser l'accès des utilisateurs ... cela semble faisable, mais en quelque sorte c'est compliqué.

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

Revenons au protocole ssh.

L'accès ssh étant utilisé pour git, vous devez sécuriser les données du serveur. L'utilisateur qui se connecte via ssh utilise sa propre connexion sur le serveur Linux, il peut donc se connecter via le client ssh et accéder à la ligne de commande du serveur.
Il n'y a pas de protection complète contre l'obtention d'un tel accès.

Mais l'utilisateur ne devrait pas être intéressé par les fichiers Linux. Les informations importantes sont stockées uniquement dans le référentiel git. Par conséquent, vous ne pouvez pas restreindre l'accès via la ligne de commande, mais Linux peut empêcher l'utilisateur de regarder des projets, à l'exclusion de ceux auxquels il participe.
Évidemment, en utilisant le système d'autorisations Linux.

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

Pour implémenter les exigences données au début de l'article, la structure de répertoires suivante est créée avec l'attribution des droits et des propriétaires:

1) répertoires de projets

dir1 (proj1: proj1,0770)
dir2 (proj2: proj2,0770)
dir3 (proj3: proj3,0770)
...
où
dir1, dir2, dir3 - répertoires du projet: projet 1, projet 2, projet 3.

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

les droits sur tous les répertoires sont définis en 0770 - un accès complet pour le propriétaire et son groupe et une interdiction complète pour tout le monde.

2) comptes de développeur

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

Le point clé est que les développeurs se voient attribuer un groupe supplémentaire de l'utilisateur système propriétaire du projet correspondant. Cette opération est effectuée par l'administrateur du serveur Linux en tant que commande unique.

Dans cet exemple, «Developer 1» fonctionne sur les projets proj1 et proj2 et «Developer 2» fonctionne sur les projets proj2 et proj3.

Si l'un des développeurs se connecte via ssh via la ligne de commande, ses droits ne seront même pas suffisants pour afficher le contenu des répertoires de projet dans lesquels il n'est pas impliqué. Lui-même ne peut rien changer à cela.

Puisque la base de ce principe est la sécurité de base des droits Linux, ce schéma est fiable. De plus, le régime est très facile à administrer.

Passons à la pratique.

Création de référentiels Git sur un serveur Linux

Nous vérifions.

[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 avec mes mains ...

 [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 référentiels d'autres personnes à partir de la ligne de commande et même de voir leur contenu.

 [dev1@server ~]$ cd /var/gitservertest/proj3 -bash: cd: /var/gitservertest/proj3: Permission denied [dev1@server ~]$ ls /var/gitservertest/proj3 ls: cannot open directory /var/gitservertest/proj3: Permission denied 

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

Une question demeure, si un développeur introduit un nouveau fichier, le reste des développeurs ne peut pas le modifier, car il le possède lui-même (par exemple, dev1), et non l'utilisateur propriétaire du projet (par exemple, proj1). Étant donné que nous avons un référentiel de serveur, vous devez tout d'abord savoir comment le répertoire ".git" est organisé et si de nouveaux fichiers sont créés.

Création d'un référentiel Git local et push vers un serveur Git

Passons à la machine cliente.

 Microsoft Windows [Version 6.1.7601] (c)   (Microsoft Corp.), 2009.   . C:\gittest>git init . Initialized empty Git repository in C:/gittest/.git/ C:\gittest>echo "test dev1 to proj2" > test1.txt C:\gittest>git add . C:\gittest>git status On branch master No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: test1.txt C:\gittest>git commit -am "new test file added" [master (root-commit) a7ac614] new test file added 1 file changed, 1 insertion(+) create mode 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: Counting objects: 3, done. Writing objects: 100% (3/3), 243 bytes | 243.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To ssh://10.1.1.11/var/gitservertest/proj2 * [new branch] master -> master C:\gittest> 

Dans le même temps, de nouveaux fichiers se forment 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 directories, 18 files [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]$ 

Lorsque les modifications sont téléchargées sur le serveur Git, des fichiers et des répertoires supplémentaires sont créés et, en même temps, l'utilisateur qui effectue le téléchargement est le propriétaire. 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 de développement n'aidera pas, car alors comment travailler sur plusieurs projets?). Dans ce cas, l'utilisateur dev2 ne pourra pas modifier les fichiers créés par l'utilisateur dev1, ce qui est lourd de violation de fonctionnalité.

Linux chown - changer le propriétaire d'un fichier par un utilisateur régulier

Le propriétaire du fichier ne peut pas modifier sa propriété. Mais il peut modifier le groupe du fichier qui lui appartient, puis ce fichier peut être disponible pour être modifié par d'autres utilisateurs du même groupe. Voilà ce dont nous avons besoin.

Utilisation de git hook

Le répertoire de travail du hook est le répertoire racine du projet. hook est un exécutable qui s'exécute sous l'utilisateur qui pousse. sachant cela, nous pouvons réaliser notre plan.

 [dev1@server proj2]$ mv hooks/post-update{.sample,} [dev1@server proj2]$ sed -i '2,$ s/^/#/' hooks/post-update [dev1@server proj2]$ cat <<< 'find . -group $(whoami) -exec chgrp proj2 '"'"'{}'"'"' \;' >> hooks/post-update 

soit juste

 vi hooks/post-update 

Retour à 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 file changed, 1 insertion(+) C:\gittest>git push origin master dev1:dev1@10.1.1.11's password: d22c66e..b045e22 master -> master 

Sur le serveur Git, on vérifie après le commit l'opération du script hook post-mise à jour

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

- vide, tout va bien.

Connecter un deuxième développeur à Git

Nous imiterons 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 files changed, 2 insertions(+) create mode 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 

- vide à nouveau, tout fonctionne.

Suppression d'un projet Git et téléchargement d'un projet à partir d'un serveur Git

Eh bien, vous pouvez à nouveau vous assurer que toutes les modifications sont conservées.

 C:\gittest>rd /S /Q .       ,       . 

- Pour supprimer un projet Git, effacez complètement le répertoire. Nous allons supporter l'erreur générée, car il est impossible de supprimer le répertoire en cours pour cette commande, mais nous avons juste besoin de ce comportement.

 C:\gittest>dir   C:\gittest 21.06.2019 08:43 <DIR> . 21.06.2019 08:43 <DIR> .. C:\gittest>git clone ssh://dev2@10.1.1.11/var/gitservertest/proj2 Cloning into 'proj2'... dev2@10.1.1.11's password: C:\gittest>cd proj2 C:\gittest\proj2>dir   C:\gittest\proj2 21.06.2019 08:46 <DIR> . 21.06.2019 08:46 <DIR> .. 21.06.2019 08:46 114 test1.txt 21.06.2019 08:46 19 test2.txt C:\gittest\proj2>type test1.txt "test dev1 to proj2" "dev1 added some omre" "dev1 3rd line" "!!! dev2 added this" C:\gittest\proj2>type test2.txt "!!! dev2 wrote" 

Partage d'accès dans Git

Maintenant, assurons-nous 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:\gittest\proj2>git remote remove origin C:\gittest\proj2>git remote add origin "ssh://dev2@10.1.1.11/var/gitservertest/proj1" C:\gittest\proj2>git push origin master dev2@10.1.1.11's password: fatal: '/var/gitservertest/proj1' does not appear to be a git repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. 

Autorisez maintenant l'accès

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

et après cela, tout fonctionne.

 C:\gittest\proj2>git push origin master dev2@10.1.1.11's password: To ssh://10.1.1.11/var/gitservertest/proj1 * [new branch] master -> master 

Information additionnelle

De plus, en cas de problème avec les autorisations par défaut lors de la création de fichiers et de répertoires, dans CentOS, vous pouvez utiliser la commande

 setfacl -Rd -mo::5 -mg::7 /var/gitservertest 

Dans l'article, vous pouvez également tomber sur de petites choses utiles:

• comment construire une arborescence de répertoires sous Linux
• comment sed pour transférer une plage d'adresses d'une certaine ligne à la fin du fichier, c'est-à-dire pour faire un remplacement dans sed dans toutes les lignes sauf la première ligne
• Comment trouver sur Linux pour inverser un terme de recherche
• comment dans le shell Linux pour boucler plusieurs lignes sur une seule ligne
• comment échapper aux guillemets simples dans bash
• comment supprimer le répertoire avec tout le contenu sur la ligne de commande Windows
• Comment utiliser bash mv pour renommer un fichier sans le réécrire

Merci de votre attention.