ProHoster > Log > administrasjon > Organisering av flerbrukertilgang til GIT-serveren

Organisering av flerbrukertilgang til GIT-serveren

Når du installerer og konfigurerer en Git-server, oppstår spørsmålet om å organisere tilgang for flere brukere til flere prosjekter. Jeg undersøkte problemet og fant en løsning som tilfredsstilte alle mine krav: enkel, sikker, pålitelig.

Mine ønsker er:

  • hver bruker kobler til sin egen konto
  • Flere brukere kan jobbe med ett prosjekt
  • samme bruker kan jobbe med flere prosjekter
  • hver bruker har kun tilgang til de prosjektene han jobber med
  • Det skal være mulig å koble til via kommandolinjen, og ikke bare gjennom et slags webgrensesnitt

Det ville også vært flott:

  • gi skrivebeskyttede tillatelser til kontrollerende personer
  • Administrer brukertilgangsrettigheter praktisk i Git

Oversikt over mulige alternativer for tilgang til GIT-serveren

Først av alt må du vite hva du skal velge mellom, så her er en rask oversikt over Git-protokoller.

  • ssh - en spesielt opprettet brukerkonto brukes for å få tilgang til serveren.
    • Det er merkelig at Git ikke utelukker fra sine anbefalinger bruken av én konto for å få tilgang til alle depotene. Dette oppfyller ikke mine krav i det hele tatt.
    • Du kan bruke flere kontoer, men hvordan kan du begrense brukertilgang til bare visse kataloger?
      • Å lukke seg inn i hjemmekatalogen er ikke egnet, fordi det er vanskelig å organisere skrivetilgang der for andre brukere
      • Å bruke symbolkoblinger fra hjemmekatalogen din er også vanskelig fordi Git ikke tolker dem som lenker
      • Det er mulig å begrense tilgangen til tolken, men det er ingen full garanti for at det alltid vil fungere
        • Du kan generelt koble til din egen kommandotolk for slike brukere, men
          • For det første er dette allerede en slags vanskelig avgjørelse,
          • og for det andre kan dette omgås.

    Men det er kanskje ikke et problem at brukeren vil kunne utføre noen kommandoer?.. Generelt kan ikke denne metoden utelukkes hvis du finner ut nøyaktig hvordan den skal brukes. Vi kommer tilbake til denne metoden senere, men foreløpig vil vi kort vurdere de andre alternativene, kanskje det vil være noe enklere.

  • Den lokale git-protokollen kan brukes i kombinasjon med sshfs, flere brukere kan brukes, men i hovedsak det samme som det forrige tilfellet
  • http – skrivebeskyttet
  • git er skrivebeskyttet
  • https - vanskelig å installere, du trenger ekstra programvare, et slags kontrollpanel for å organisere brukertilgang... det ser gjennomførbart ut, men på en eller annen måte er alt komplisert.

Bruke ssh-protokollen for å organisere flerbrukertilgang til Git-serveren

La oss gå tilbake til ssh-protokollen.

Siden du bruker ssh-tilgang for git, må du sørge for sikkerheten til serverdataene. Brukeren som kobler til via ssh bruker sin egen pålogging på Linux-serveren, slik at de kan koble seg til via ssh-klienten og få tilgang til serverens kommandolinje.
Det er ingen fullstendig beskyttelse mot slik tilgang.

Men brukeren bør ikke være interessert i Linux-filer. Vesentlig informasjon lagres kun i git-depotet. Derfor er det mulig å ikke begrense tilgangen via kommandolinjen, men å bruke Linux-verktøy for å forby brukeren å se prosjekter, unntatt de han deltar i.
Det åpenbare valget er å bruke Linux-tillatelsessystemet.

Som allerede nevnt, er det mulig å bruke kun én konto for ssh-tilgang. Denne konfigurasjonen er usikker for flere brukere, selv om den er inkludert i listen over anbefalte git-alternativer.

For å implementere kravene gitt i begynnelsen av artikkelen, opprettes følgende katalogstruktur med tildeling av rettigheter og eiere:

1) prosjektkataloger

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
der
dir1, dir2, dir3 - prosjektkataloger: prosjekt 1, prosjekt 2, prosjekt 3.

proj1:proj1, proj2:proj2, proj3:proj3 er spesiallagde Linux-brukere som er tildelt som eiere av de tilsvarende prosjektkatalogene.

tillatelser for alle kataloger er satt til 0770 - full tilgang for eieren og gruppen hans og et fullstendig forbud for alle andre.

2) utviklerkontoer

Разработчик 1: dev1:dev1,proj1,proj2
Разработчик 2: dev2:dev2,proj2,proj3

Nøkkelpunktet er at utviklere blir tildelt en ekstra gruppe av systembrukerens eier av det tilsvarende prosjektet. Dette gjøres av Linux-serveradministratoren med én kommando.

I dette eksemplet jobber "Utvikler 1" med prosjektene proj1 og proj2, og "Utvikler 2" jobber med prosjektene proj2 og proj3.

Hvis noen av utviklerne kobler til via ssh via kommandolinjen, vil ikke rettighetene deres være tilstrekkelige engang til å se innholdet i prosjektkataloger de ikke deltar i. Han kan ikke endre dette selv.

Siden grunnlaget for dette prinsippet er den grunnleggende sikkerheten til Linux-rettigheter, er denne ordningen pålitelig. I tillegg er ordningen svært enkel å administrere.

La oss fortsette å øve.

Opprette Git-repositories på en Linux-server

La oss sjekke.

[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

Jeg er lei av å skrive for hånd...

[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

Vi er overbevist om at det er umulig å få tilgang til andres depoter fra kommandolinjen og til og med se innholdet.

[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

Samarbeid med flere utviklere om det samme prosjektet i Git

Ett spørsmål gjenstår, hvis en utvikler introduserer en ny fil, kan ikke andre utviklere endre den, fordi han selv er eieren av den (for eksempel dev1), og ikke brukereieren av prosjektet (for eksempel proj1). Siden vi har et lager på serversiden, må vi først og fremst vite hvordan ".git"-katalogen er strukturert og om nye filer opprettes.

Opprette et lokalt Git-lager og skyve til Git-serveren

La oss gå videre til klientmaskinen.

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://[email protected]/var/gitservertest/proj2"

C:gittest>git push origin master
dev1:[email protected]'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>

Samtidig opprettes nye filer på serveren, og de tilhører brukeren som utførte pushet

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

Når du laster opp endringer til Git-serveren, opprettes flere filer og kataloger, og eieren deres er faktisk brukeren som gjør opplastingen. Men da tilsvarer gruppen av disse filene og katalogene også hovedgruppen til denne brukeren, det vil si dev1-gruppen for dev1-brukeren og dev2-gruppen for dev2-brukeren (å endre hovedgruppen til utviklerbrukeren vil ikke hjelpe, for hvordan kan du jobbe med flere prosjekter?). I dette tilfellet vil ikke bruker dev2 kunne endre filer opprettet av bruker dev1, noe som kan føre til funksjonsbrudd.

Linux chown - endre eieren av en fil av en vanlig bruker

Eieren av en fil kan ikke endre eierskapet. Men han kan endre gruppen til en fil som tilhører ham, og så kan denne filen endres av andre brukere som er i samme gruppe. Det er det vi trenger.

Bruker Git hook

Arbeidskatalogen for hook er rotkatalogen til prosjektet. hook er en kjørbar fil som kjører under brukeren som trykker. Når vi vet dette, kan vi gjennomføre planene våre.

[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

eller bare 

vi hooks/post-update

La oss gå tilbake til klientmaskinen.

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:[email protected]'s password:
   d22c66e..b045e22  master -> master

På Git-serveren sjekker vi driften av hook post-update scriptet etter commit 

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

- tom, alt er bra.

Koble til en annen utvikler i Git

La oss simulere arbeidet til den andre utvikleren.

På klienten

C:gittest>git remote remove origin

C:gittest>git remote add origin "ssh://[email protected]/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
[email protected]'s password:
   b045e22..55d49a6  master -> master

Og på samme tid, på serveren...

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

— tom igjen, alt fungerer.

Slette et Git-prosjekt og laste ned prosjektet fra Git-serveren

Vel, du kan igjen sørge for at alle endringene er lagret.

C:gittest>rd /S /Q .
Процесс не может получить доступ к файлу, так как этот файл занят другим процессом.

- for å slette et Git-prosjekt, slett katalogen helt. La oss tåle feilen som genereres, siden det er umulig å slette den gjeldende katalogen ved å bruke denne kommandoen, men dette er akkurat den oppførselen vi trenger.

C:gittest>dir
 Содержимое папки C:gittest

21.06.2019  08:43    <DIR>          .
21.06.2019  08:43    <DIR>          ..

C:gittest>git clone ssh://[email protected]/var/gitservertest/proj2
Cloning into 'proj2'...
[email protected]'s password:

C:gittest>cd proj2

C:gittestproj2>dir
 Содержимое папки C:gittestproj2

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: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"

Deler tilgang i Git

La oss nå sørge for at selv gjennom Git ikke kan den andre utvikleren få tilgang til Proj1-prosjektet, som han ikke jobber med.

C:gittestproj2>git remote remove origin

C:gittestproj2>git remote add origin "ssh://[email protected]/var/gitservertest/proj1"

C:gittestproj2>git push origin master
[email protected]'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.

Nå tillater vi tilgang

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

og etter det fungerer alt.

C:gittestproj2>git push origin master
[email protected]'s password:
To ssh://10.1.1.11/var/gitservertest/proj1
 * [new branch]      master -> master

For mer informasjon,

I tillegg, hvis det er et problem med standardtillatelsene når du oppretter filer og kataloger, i CentOS kan du bruke kommandoen

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

Også i artikkelen kan du snuble over små nyttige ting:

  • hvordan bygge et katalogtre i Linux
  • hvordan sende en rekke adresser i sed fra en bestemt linje til slutten av filen, det vil si å gjøre en erstatning i sed i alle linjer unntatt den første linjen
  • Hvordan invertere en søkebetingelse i Linux-finn
  • Hvordan sende flere linjer inn i en løkke ved å bruke en one-liner i Linux-skallet
  • Hvordan unnslippe enkle sitater i bash
  • hvordan slette en katalog med alt innholdet på kommandolinjen i Windows
  • Hvordan bruke bash mv til å gi nytt navn til en fil uten å skrive den om igjen

Takk for oppmerksomheten.

Kilde: www.habr.com

Legg til en kommentar