ProHoster > Blog > Beheer > Organisatie van multi-user toegang op de GIT-server

Organisatie van multi-user toegang op de GIT-server

Bij het opzetten en configureren van een Git-server rijst de vraag hoe de toegang voor meerdere gebruikers tot verschillende projecten te organiseren. Ik heb het onderwerp onderzocht en een oplossing gevonden die aan al mijn eisen voldoet: simpel, veilig en betrouwbaar.

Mijn wensen zijn als volgt:

  • iedere gebruiker logt in met zijn eigen account
  • aan één project kunnen meerdere gebruikers werken
  • dezelfde gebruiker kan aan meerdere projecten werken
  • iedere gebruiker heeft alleen toegang tot de projecten waar hij aan werkt
  • er moet de mogelijkheid zijn om toegang te krijgen via de opdrachtregel, niet alleen via een webinterface

Het zou ook geweldig zijn om:

  • rechten alleen-lezen te geven voor toezichthoudende personen
  • de rechten van gebruikers in Git gemakkelijk te beheren

Overzicht van mogelijke toegangsmogelijkheden op de GIT-server

Allereerst is het nodig te weten waaruit te kiezen, daarom is hier een kort overzicht van Git-protocollen.

  • ssh β€” voor toegang tot de server wordt een speciaal aangemaakt gebruikersaccount gebruikt.
    • Het is vreemd dat Git in zijn aanbevelingen het gebruik van één account voor toegang tot alle repositories niet uitsluit. Dit voldoet niet aan mijn eisen.
    • Je kunt meerdere accounts gebruiken, maar hoe beperk je de toegang van een gebruiker tot bepaalde mappen?
      • Thuisdirectory afsluiten is niet geschikt, omdat het moeilijk is om daar schrijf toegang voor andere gebruikers te organiseren
      • Het gebruik van symbolische links vanuit de thuisdirectory is ook moeilijk omdat Git ze niet als links interpreteert
      • Toegang tot de interpreter beperken kan, maar er is geen volledige garantie dat dit altijd werkt
        • Je kunt voor zulke gebruikers zelfs je eigen opdrachtinterpreter aansluiten, maar,
          • ten eerste is dit al een ingewikkelde oplossing,
          • en ten tweede kan dit worden omzeild.

    Maar misschien is het geen probleem dat een gebruiker alle opdrachten kan uitvoeren?.. Laten we deze methode voorlopig niet uitsluiten, als we maar bedenken hoe we deze kunnen gebruiken. Laten we nu kort de andere alternatieven bekijken, misschien is daar iets eenvoudiger.

  • Het git lokale protocol kan worden gebruikt in combinatie met sshfs, meerdere gebruikers zijn mogelijk, maar in wezen is het hetzelfde als het vorige geval.
  • http β€” alleen-lezen
  • git β€” alleen-lezen
  • https β€” moeilijk in te stellen, vereist extra software, iets bedieningspaneel voor het organiseren van toegang voor gebruikers... ziet eruit als uitvoerbaar, maar het is allemaal best ingewikkeld.

Gebruik van het ssh-protocol voor het organiseren van multi-user toegang tot de Git-server.

Laten we teruggaan naar het ssh-protocol.

Aangezien er toegang via ssh voor git wordt gebruikt, moet de veiligheid van de gegevens op de server worden gewaarborgd. Een gebruiker die via ssh inlogt, gebruikt zijn eigen login op de server Linux, waardoor hij via een ssh-client kan inloggen en toegang krijgt tot de opdrachtregel van de server.
Er is geen volledige bescherming tegen het verkrijgen van dergelijke toegang.

Maar voor de gebruiker hoeven de Linux-bestanden geen interesse te hebben. Belangrijke informatie wordt alleen in de git-repository opgeslagen. Daarom kan de toegang via de opdrachtregel niet worden beperkt, maar kunnen de Linux-middelen worden gebruikt om de gebruiker te verbieden projecten te bekijken, behalve die waarin hij betrokken is.
Het is duidelijk om het Linux-rechtersysteem te gebruiken.

Zoals eerder vermeld, is het mogelijk om slechts één account voor ssh-toegang te gebruiken. Deze configuratie is onveilig voor meerdere gebruikers, hoewel deze methode op de lijst van aanbevolen git-opties staat.

Om aan de in het begin van het artikel genoemde vereisten te voldoen, wordt de volgende directorystructuur met toegewezen rechten en eigenaren gemaakt:

1) projectdirectories

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
…
waar
dir1, dir2, dir3 β€” projectdirectories: project 1, project 2, project 3.

proj1:proj1, proj2:proj2, proj3:proj3 β€” speciaal aangemaakte Linux-gebruikers die als eigenaren van de bijbehorende projectdirectories zijn aangesteld.

Rechten voor alle directories worden ingesteld op 0770 β€” volledige toegang voor de eigenaar en zijn groep en een volledig verbod voor alle anderen.

2) ontwikkelaarsaccounts

Ontwikkelaar 1: dev1:dev1,proj1,proj2
Ontwikkelaar 2: dev2:dev2,proj2,proj3

Het belangrijkste punt is dat ontwikkelaars een extra groep van de systeemgebruiker-eigenaar van het bijbehorende project krijgen toegewezen. Dit wordt gedaan door de Linux-serveradministrator met één opdracht.

In dit voorbeeld werkt 'Ontwikkelaar 1' aan project proj1 en proj2, terwijl 'Ontwikkelaar 2' aan de projecten proj2 en proj3 werkt.

Als een van de Ontwikkelaars via ssh verbinding maakt met de opdrachtregel, hebben ze niet genoeg rechten zelfs om de inhoud van de projectmappen te bekijken waarvan ze geen deel uitmaken. Dit kan hij of zij zelf niet veranderen.

Aangezien de basis van dit principe de basisveiligheid van Linux-rechten is, is dit schema betrouwbaar. Bovendien is het schema zeer eenvoudig te beheren.

Laten we naar de praktijk gaan.

Het aanmaken van Git-repositories op een Linux-server

We controleren.

[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

verveeld met handmatig invoeren...

[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

We zorgen ervoor dat we vanuit de opdrachtregel geen toegang hebben tot andermans repositories en zelfs de inhoud ervan niet kunnen bekijken.

[dev1@server ~]$ cd /var/gitservertest/proj3
-bash: cd: /var/gitservertest/proj3: Toegang geweigerd
[dev1@server ~]$ ls /var/gitservertest/proj3
ls: kan map /var/gitservertest/proj3 niet openen: Toegang geweigerd

Samenwerking in Git tussen meerdere ontwikkelaars aan één project

Er blijft één vraag over: als één ontwikkelaar een nieuw bestand toevoegt, kunnen de andere ontwikkelaars het niet wijzigen omdat hij zelf de eigenaar is (bijvoorbeeld dev1), en niet de projectgebruikers-eigenaar (bijvoorbeeld proj1). Aangezien we een serverrepository hebben, moeten we eerst begrijpen hoe de map '.git' is opgebouwd en of er nieuwe bestanden worden aangemaakt.

Het aanmaken van een lokale Git-repository en push naar de Git-server

Laten we naar de clientmachine gaan.

Microsoft Windows [Version 6.1.7601]
(c) Microsoft Corporation, 2009. Alle rechten voorbehouden.

C:gittest>git init .
Lege Git-repository geΓ―nitieerd in C: /gittest / .git / 

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

C:gittest>git add .

C:gittest>git status
Op branch master
Nog geen commits
Wijzigingen om te worden gecommit:
  (gebruik "git rm --cached <bestand>..." om te unstagen)
        nieuw bestand:   test1.txt

C:gittest>git commit -am "nieuwe testbestand toegevoegd"
[master (root-commit) a7ac614] nieuwe testbestand toegevoegd
 1 bestand gewijzigd, 1 invoeging(+)
 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 wachtwoord:
Objecten tellen: 3, gedaan.
Objecten schrijven: 100% (3/3), 243 bytes | 243.00 KiB/s, gedaan.
Totaal 3 (delta 0), hergebruikt 0 (delta 0)
Naar ssh://10.1.1.11/var/gitservertest/proj2
 * [nieuwe branch]      master -> master

C:gittest>

Op hetzelfde moment worden er nieuwe bestanden op de server aangemaakt, en deze behoren tot de gebruiker die de push heeft uitgevoerd.

[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]$

Wanneer wijzigingen naar de server worden geladen, worden er extra bestanden en mappen aangemaakt, en de eigenaar van deze bestanden is inderdaad de gebruiker die de upload uitvoert. Maar dan komt de groep van deze bestanden en mappen ook overeen met de primaire groep van die gebruiker, dat wil zeggen, groep dev1 voor gebruiker dev1 en groep dev2 voor gebruiker dev2 (het verandert van primaire groep niet helpt, omdat hoe dan ook te werken aan meerdere projecten?). In dat geval kan gebruiker dev2 de door gebruiker dev1 gemaakte bestanden niet wijzigen, wat schadelijk kan zijn voor de functionaliteit.

Linux chown β€” wijziging van de eigenaar van een bestand door een normale gebruiker.

De eigenaar van een bestand kan zijn toewijzing niet wijzigen. Maar hij kan de groep van het bestand waarmee hij verbonden is, wijzigen, zodat dit bestand kan worden gewijzigd door andere gebruikers die in dezelfde groep zitten. Dit is wat we nodig hebben.

Gebruik van Git hook

De werkdirectory voor hook is de rootdirectory van het project. Hook is een uitvoerbaar bestand dat wordt uitgevoerd onder de gebruiker die de push doet. Dit weten we, zodat we de bedoeling kunnen uitvoeren.

[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

of gewoon

vi hooks/post-update

Laten we teruggaan naar de clientmachine.

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 bestand gewijzigd, 1 invoeging(+)

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

Op de Git-server controleren we na de commit of de hook post-update script werkt.

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

β€” leeg, alles werkt normaal.

De tweede ontwikkelaar aansluiten in Git

Laten we de werkzaamheden van de tweede ontwikkelaar simuleren.

Op de 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 bestanden gewijzigd, 2 invoegingen(+)
 create mode 100644 test2.txt

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

En ondertussen, op de server...

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

β€” weer leeg, alles werkt.

Een Git-project verwijderen en een project van de Git-server downloaden

We kunnen nog een keer controleren of alle wijzigingen zijn opgeslagen.

C:gittest>rd /S /Q .
Het proces kan geen toegang krijgen tot het bestand omdat dit bestand door een ander proces wordt gebruikt.

β€” om het Git-project te verwijderen, wissen we simpelweg de directory volledig. We accepteren de foutmelding die wordt weergegeven, aangezien het niet mogelijk is om de huidige directory met dit commando te verwijderen, maar dat is precies het gedrag dat we nodig hebben.

C:gittest>dir
 Inhoud van de map 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
Klonen in 'proj2'...
dev2@10.1.1.11's password:

C:gittest>cd proj2

C:gittestproj2>dir
 Inhoud van de map 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"

Toegangscontrole in Git

Laten we controleren of de tweede ontwikkelaar via Git geen toegang kan krijgen tot het project Proj1 waar hij niet aan werkt.

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' lijkt geen git-repository te zijn
fatal: Kon niet lezen van de externe repository.

Zorg ervoor dat u de juiste toegangsrechten heeft
en dat de repository bestaat.

Laten we nu toegang verlenen

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

en daarna werkt alles.

C:gittestproj2>git push origin master
dev2@10.1.1.11's password:
Naar ssh://10.1.1.11/var/gitservertest/proj1
 * [nieuwe tak]      master -> master

Aanvullende informatie

Bovendien, als er een probleem is met de standaard rechten bij het aanmaken van bestanden en mappen, kan je in CentOS het commando gebruiken

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

Ook in het artikel kom je nuttige kleine dingen tegen:

  • hoe je in Linux een directorystructuur opbouwt
  • hoe je in sed een bereik van adressen doorgeeft van een bepaalde regel tot het einde van het bestand, dat wil zeggen, een vervanging in sed doet in alle regels behalve de eerste regel
  • Hoe je in Linux find de zoekvoorwaarde omkeert
  • hoe je in de Linux shell meerdere regels doorgeeft aan een loop via een enkele regel
  • hoe je in bash enkele aanhalingstekens kunt escaperen
  • hoe je in de opdrachtprompt van Windows een directory met al zijn inhoud kunt verwijderen
  • Hoe je met bash mv een bestand hernoemt zonder het opnieuw te schrijven

Bedankt voor uw aandacht.

Bron: habr.com

Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers πŸ”₯ Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers | ProHoster