ProHoster > Blog > administration > Organisering af flerbrugeradgang til GIT-serveren

Organisering af flerbrugeradgang til GIT-serveren

Når du installerer og konfigurerer en Git-server, opstår spørgsmålet om at organisere adgang for flere brugere til flere projekter. Jeg undersøgte spørgsmålet og fandt en løsning, der opfylder alle mine krav: enkel, sikker, pålidelig.

Mine ønsker er:

  • hver bruger forbinder med deres egen konto
  • Flere brugere kan arbejde på det samme projekt
  • den samme bruger kan arbejde på flere projekter
  • hver bruger har kun adgang til de projekter, han arbejder på
  • det burde være muligt at oprette forbindelse via kommandolinjen, og ikke kun gennem en form for webgrænseflade

Det ville også være fantastisk:

  • give læserettigheder til kontrollerende personer
  • nemt at administrere brugertilladelser i Git

Oversigt over mulige muligheder for at få adgang til GIT-serveren

Først og fremmest skal du vide, hvad du skal vælge imellem, så en kort oversigt over Git-protokollerne.

  • ssh - en specielt oprettet brugerkonto bruges til at få adgang til serveren.
    • det er mærkeligt, at Git ikke fraråder at bruge én konto til at få adgang til alle repositories. Dette opfylder slet ikke mine krav.
    • Du kan bruge flere konti, men hvordan kan du begrænse en brugers adgang til kun bestemte mapper?
      • Lukning af hjemmebiblioteket er ikke egnet, fordi det er svært at organisere skriveadgang for andre brugere der
      • Det er også vanskeligt at bruge symbolske links fra hjemmemappen, fordi Git ikke fortolker dem som links.
      • Begræns adgangen til tolken, ja, det kan du, men der er ingen fuld garanti for, at det altid vil virke
        • Du kan generelt tilslutte din egen kommandotolk til sådanne brugere, men
          • For det første er dette allerede en form for svær beslutning,
          • og 2, kan den omgås.

    Men måske er det ikke et problem, at brugeren vil være i stand til at udføre nogen kommandoer?.. Generelt kan denne metode ikke udelukkes, hvis du finder ud af præcis, hvordan den skal bruges. Vi vender tilbage til denne metode senere, men for nu vil vi kort overveje de resterende alternativer, måske vil der være noget enklere.

  • git lokal protokol kan bruges i kombination med sshfs, flere brugere kan bruges, men det er stort set det samme som det forrige tilfælde
  • http - skrivebeskyttet
  • git er skrivebeskyttet
  • https er svært at installere, du har brug for yderligere software, en form for kontrolpanel til at organisere brugeradgang ... det ser muligt ud, men på en eller anden måde er alt kompliceret.

Brug af ssh-protokollen til at organisere flerbrugeradgang til Git-serveren

Lad os vende tilbage til ssh-protokollen.

Da ssh-adgang bruges til git, skal serverdataene være sikre. Brugeren, der forbinder via ssh, bruger deres eget login på Linux-serveren, så de kan oprette forbindelse via ssh-klienten og få adgang til serverens kommandolinje.
Der er ingen fuldstændig beskyttelse mod at få sådan adgang.

Men brugeren bør ikke være interesseret i Linux-filer. Meningsfuld information gemmes kun i git-lageret. Derfor kan du ikke begrænse adgangen via kommandolinjen, men ved hjælp af Linux forbyde brugeren at se projekter, med undtagelse af dem, han deltager i.
Det er oplagt at bruge Linux-tilladelsessystemet.

Som allerede nævnt er det muligt kun at bruge én konto til ssh-adgang. Denne konfiguration er usikker for flere brugere, selvom den er inkluderet i git's liste over anbefalede muligheder.

For at implementere kravene angivet i begyndelsen af ​​artiklen oprettes følgende mappestruktur med tildeling af rettigheder og ejere:

1) projektmapper

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
где
dir1, dir2, dir3 - projektmapper: projekt 1, projekt 2, projekt 3.

proj1:proj1, proj2:proj2, proj3:proj3 er specielt oprettede Linux-brugere, der er tildelt som ejere af de respektive projektmapper.

rettighederne til alle mapper er sat til 0770 - fuld adgang for ejeren og hans gruppe, og et fuldstændigt forbud for alle andre.

2) udviklerkonti

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

Nøglepunktet er, at udviklerne tildeles en ekstra gruppe af systembrugeren, som ejer det tilsvarende projekt. Dette gøres af Linux-serveradministratoren med én kommando.

I dette eksempel arbejder udvikler 1 på projekterne proj1 og proj2, og udvikler 2 arbejder på projekterne proj2 og proj3.

Hvis nogen af ​​udviklerne opretter forbindelse via ssh via kommandolinjen, vil hans rettigheder ikke være nok, selv til at se indholdet af bibliotekerne for projekter, hvori han ikke deltager. Han kan ikke selv ændre det.

Da grundlaget for dette princip er den grundlæggende sikkerhed for Linux-rettigheder, er denne ordning pålidelig. Derudover er ordningen meget nem at administrere.

Lad os fortsætte med at øve.

Oprettelse af Git Repositories på en Linux-server

Vi tjekker.

[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

træt af at skrive...

[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 overbeviste om, at det er umuligt at få adgang til andres arkiver fra kommandolinjen og endda se deres indhold.

[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

Samarbejde i Git af flere udviklere på et projekt

Et spørgsmål står tilbage, hvis en udvikler introducerer en ny fil, så kan andre udviklere ikke ændre den, fordi han selv er dens ejer (for eksempel dev1), og ikke brugeren, der ejer projektet (for eksempel proj1). Da vi har et serverlager, skal vi først og fremmest vide, hvordan ".git"-mappen er arrangeret, og om der oprettes nye filer.

Opret et lokalt Git-lager og skub til en Git-server

Lad os 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 genereres nye filer på serveren, og de tilhører den bruger, der har udført 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 ændringerne uploades til Git-serveren, oprettes yderligere filer og mapper, som faktisk ejes af uploaderen. Men så svarer gruppen af ​​disse filer og mapper også til hovedgruppen for denne bruger, det vil sige dev1-gruppen for dev1-brugeren og dev2-gruppen for dev2-brugeren (det hjælper ikke at ændre udviklerbrugerens hovedgruppe, for da hvordan man arbejder på flere projekter?). I dette tilfælde vil dev2-brugeren ikke være i stand til at ændre de filer, der er oprettet af dev1-brugeren, og dette er fyldt med en krænkelse af funktionaliteten.

Linux chown - ændring af ejeren af ​​en fil af en normal bruger

Ejeren af ​​en fil kan ikke ændre dens ejerskab. Men han kan ændre gruppen af ​​en fil, der tilhører ham, og så kan denne fil ændres af andre brugere, der er i samme gruppe. Det er det, vi har brug for.

Brug af Git Hook

Arbejdsmappen for hook er rodmappen for projektet. hook er en eksekverbar fil, der kører under brugeren, der laver push. ved at vide dette, kan vi udføre vores planer.

[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

Lad os gå tilbage 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 skal du kontrollere arbejdet med hook-efter-opdateringsscriptet efter commit 

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

- tom, alt er fint.

Tilslutning af en anden udvikler til Git

Lad os simulere den anden udviklers arbejde.

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

- igen tom, alt virker.

Sletning af et Git-projekt og indlæsning af et projekt fra en Git-server

Nå, du kan igen sikre dig, at alle ændringerne er blevet gemt.

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

- for at fjerne et Git-projekt skal du blot rydde mappen helt. Lad os affinde os med den givne fejl, da det er umuligt at slette den aktuelle mappe med denne kommando, men det er præcis den adfærd, vi har brug for.

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 adgang i Git

Lad os nu sikre os, at den anden udvikler ikke kan få adgang til Proj1-projektet gennem Git, som han ikke arbejder på.

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.

Tillad nu adgang

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

og derefter virker 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 mere information,

Derudover, hvis der er et problem med standardtilladelserne ved oprettelse af filer og mapper, på CentOS kan du bruge kommandoen

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

Også i artiklen kan du falde over små nyttige ting:

  • hvordan man bygger et mappetræ i linux
  • hvordan man sender en række adresser fra en bestemt linje til slutningen af ​​filen i sed, det vil sige at foretage en erstatning i sed i alle linjer undtagen den første linje
  • Sådan inverteres søgetilstand i Linux-find
  • hvordan man passerer flere linjer gennem en one-liner i en linux shell
  • hvordan man undslipper enkelte citater i bash
  • hvordan man sletter en mappe med alt indhold i Windows kommandolinje
  • Sådan omdøbes en fil ved hjælp af bash mv uden at omskrive den

Tak for din opmærksomhed.

Kilde: www.habr.com

Tilføj en kommentar