ProHoster > Blogi > Haldamine > Mitme kasutaja juurdepÀÀsu korraldamine GIT serveris

Mitme kasutaja juurdepÀÀsu korraldamine GIT serveris

Git-serveri seadistamisel ja konfigureerimisel tekib kĂŒsimus, kuidas korraldada juurdepÀÀsu mitmele kasutajale mitmele projektile. Olen uurimistööd teinud ja leidnud lahenduse, mis vastab kĂ”ikidele minu nĂ”udmistele: lihtne, turvaline ja usaldusvÀÀrne.

Minu soovid on jÀrgmised:

  • iga kasutaja logib sisse oma isikliku kontoga
  • ĂŒhe projekti kallal vĂ”ivad töötada mitu kasutajat
  • ĂŒks ja sama kasutaja vĂ”ib töötada mitme projekti kallal
  • iga kasutaja pÀÀseb ligi ainult neile projektidele, millega ta tegeleb
  • peab olema vĂ”imalik ĂŒhendada kĂ€surealt, mitte ainult mingisuguse veebiliidese kaudu

Samuti oleks tore:

  • anda lugemisĂ”igused vaid jĂ€relevalveisikutele
  • mugav hallata kasutajate juurdepÀÀsuĂ”igusi Git'is

Ülevaade vĂ”imalike ligipÀÀsup rotokollide kohta GIT serveris

Esmalt on oluline teada, millest valida, seega lĂŒhike ĂŒlevaade Git protokollidest.

  • ssh — serverisse pÀÀsemiseks kasutatakse spetsiaalselt loodud kasutajakontot.
    • Imelik, et Git ei soovita kasutada ĂŒhte kontot kĂ”igi repode juurde pÀÀsemiseks. See ei vasta minu nĂ”udmistele.
    • Saab kasutada mitut kontot, aga kuidas piirata kasutaja ligipÀÀs ainult teatud kataloogidele?
      • Kodu katalooge sulgedes ei sobi, kuna on keeruline korraldada teise kasutaja kirjutamisĂ”igusi sinna.
      • SĂŒmboolsete linkide kasutamine kodukataloogist on samuti keeruline, kuna Git ei interpreteeri neid linkidena.
      • Piirata interpreteraatorile ligipÀÀsu on vĂ”imalik, kuid tĂ€ielikku garantii, et see alati töötab, ei ole.
        • VĂ”ib isegi ĂŒhendada sellistele kasutajatele oma kĂ€su interpreteeri, kuid,
          • esiteks, see on juba keeruline lahendus,
          • ja teiseks, seda on vĂ”imalik mööda minna.

    Aga ehk ei ole probleem, et kasutaja saab tĂ€ita igasuguseid kĂ€ske? .. ÜhesĂ”naga, ei saa seda meetodit vĂ€listada, kui leida, kuidas tĂ€pselt seda kasutada. KĂŒlgeme tagasi selle meetodi juurde hiljem, aga praegu vaatame kiiresti ĂŒle teised alternatiivid, ehk seal on midagi lihtsamat.

  • git kohalik protokoll vĂ”ib töötada koos sshfs-iga, mitu kasutajat on vĂ”imalik, kuid pĂ”himĂ”tteliselt on see sama, mis eelmine juhtum
  • http — ainult lugemiseks
  • git — ainult lugemiseks
  • https — keeruline seadistada, vajab tĂ€iendavat tarkvara, mingi juhtpaneel kasutajate juurdepÀÀsu korraldamiseks
 nĂ€eb vĂ€lja teostatav, kuid tundub nagu kĂ”ik on keeruline.

ssh protokolli kasutamine Git serveri mitme kasutajaga juurdepÀÀsu korraldamiseks

Naaseme ssh protokolli juurde.

Kuna git-i jaoks kasutatakse ssh kaudu juurdepÀÀsu, tuleb tagada serveri andmete turvalisus. SSH kaudu ĂŒhenduv kasutaja kasutab oma kasutajat serveril Linuxis, seega saab ta ĂŒhenduda ssh kliendi kaudu ja pÀÀseda serveri kĂ€sureale.
TÀielikku kaitset sellise juurdepÀÀsu tagamiseks ei ole.

Kuid kasutajale ei tohiks huvi pakkuda Linuxi failid. Oluline teave on salvestatud ainult git-repositooriumis. Seega ei ole vaja kÀsurea juurdepÀÀsu piirata, kuid Linuxi abil vÔib kasutajale keelata projektide vaatamise, vÀlja arvatud need, kus ta osaleb.
Ilmselgelt on soovitatav kasutada Linuxi juurdepÀÀsusĂŒsteemi.

Nagu juba mainitud, on vĂ”imalik kasutada ainult ĂŒhte kontot SSH-juurdepÀÀsuks. Selline konfiguratsioon ei ole mitme kasutaja jaoks turvaline, kuigi see meetod on soovitatavate git variantide hulgas.

Artiklis alguses esitatud nÔuete rakendamiseks luuakse jÀrgmine kaustastruktuur koos Ôiguste ja omanike mÀÀramisega:

1) projektikaustad

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)


kus
dir1, dir2, dir3 — projektikaustad: projekt 1, projekt 2, projekt 3.

proj1:proj1, proj2:proj2, proj3:proj3 — spetsiaalselt loodud Linuxi kasutajad, kellele mÀÀratakse vastavate projektide kaustade omanikuks.

KĂ”ikide kaustade Ă”igused mÀÀratakse 0770 — tĂ€ielik juurdepÀÀs omanikule ja tema rĂŒhmale, tĂ€ielik keeld kĂ”igile teistele.

2) arendajakontod

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

Oluline on see, et arendajatele mÀÀratakse lisagrupp sĂŒsteemi kasutaja-omaniku vastava projekti jaoks. Seda teeb Linuxi serveri administraator ĂŒhe kĂ€suga.

Selles nÀites töötab 'Arendaja 1' projekti proj1 ja proj2 kallal ning 'Arendaja 2' projektide proj2 ja proj3 kallal.

Kui mÔni arendajatest logib sisse ssh kaudu kÀsureal, ei piisa tal Ôigustest isegi projektide kaustade sisu vaatamiseks, milles ta ei osale. Ta ei saa seda kuidagi muuta.

Kuna selle pÔhimÔtte aluseks on Linuxi Ôiguste baasturvalisus, on see skeem usaldusvÀÀrne. Lisaks on skeem vÀga lihtne hallata.

Liigume praktika juurde.

Git-repositooriumide loomine Linuxi serveris

Kontrollime.

[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

kĂŒsitakse, et ma kĂ€sitsi ei sisestaks...

[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

Veendume, et kÀsurealt ei ole vÔimalik ligipÀÀseda teiste repositooriumidele ega isegi nende sisu vaadata.

[dev1@server ~]$ cd /var/gitservertest/proj3
-bash: cd: /var/gitservertest/proj3: JuurdepÀÀs keelatud
[dev1@server ~]$ ls /var/gitservertest/proj3
ls: ei saa avada katalooge /var/gitservertest/proj3: JuurdepÀÀs keelatud

Mitme arendaja koostöö Git'is ĂŒhes projektis

On jÀÀnud ĂŒks kĂŒsimus: kui ĂŒks arendaja lisab uue faili, siis teised arendajad ei saa seda muuta, kuna see arendaja on faili omanik (nĂ€iteks dev1), mitte projekti kasutaja-omanik (nĂ€iteks proj1). Kuna meil on serveripĂ”hine hoidla, peab esmalt teadma, kuidas on struktuurne kaust «.git» ja kas uusi faile luuakse.

Kohaliku Git hoidla loomine ja pushimine Git serverisse

Liigume kliendimasinale.

Microsoft Windows [Version 6.1.7601]
(c) Microsoft Corporation, 2009. KÔik Ôigused kaitstud.

C:gittest>git init .
TĂŒhi Git-repositoorium on loodud C:/gittest/.git/

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

C:gittest>git add .

C:gittest>git status
Peateel master
Eritusi pole veel
Muudatused, mis vajavad kinnitamist:
  (kasuta "git rm --cached <file>..." eemaldamiseks)
        uus fail:   test1.txt

C:gittest>git commit -am "uus testfail lisatud"
[master (root-commit) a7ac614] uus testfail lisatud
 1 fail muutunud, 1 sisestus(+)
 loodud reĆŸiim 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 parool:
Objektide arvestamine: 3, tehtud.
Objektide kirjutamine: 100% (3/3), 243 baiti | 243.00 KiB/s, tehtud.
Kokku 3 (delta 0), taaskasutatud 0 (delta 0)
To ssh://10.1.1.11/var/gitservertest/proj2
 * [uus haru]      master -> master

C:gittest>

Sama ajal luuakse serveris uusi faile, mis kuuluvad kasutajale, kes tegi 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 direktiivi, 18 faili
[dev1@server proj2]$ ls -l objects/75/dcd269e04852ce2f683b9eb41ecd6030c8c841
-r--r--r--. 1 dev1 dev1 54 Juuni 20 14:34 objects/75/dcd269e04852ce2f683b9eb41ecd6030c8c841
[dev1@server proj2]$

Kui muudatused serverisse laaditakse, luuakse Git'is tĂ€iendavad failid ja direktorid, ning nende omaniku rolli tĂ€idab tĂ”epoolest see kasutaja, kes laadib ĂŒles. Seega ei vasta nende failide ja direktorite rĂŒhm sellele kasutajale, vaid nende peamine rĂŒhm on seotud just selle kasutajaga, nĂ€iteks rĂŒhm dev1 kasutajale dev1 ja rĂŒhm dev2 kasutajale dev2 (arendaja peamise rĂŒhma muutmine ei aita, sest kuidas siis mitme projektiga töötada?). Sellisel juhul ei saa kasutaja dev2 muuta failide sisu, mille on loonud kasutaja dev1, mis vĂ”ib pĂ”hjustada funktsionaalsuse rikkumisi.

Linux chown — faili omaniku muutmine tavakasutaja poolt

Faili omanik ei saa muuta selle kuuluvust. Kuid ta vĂ”ib muuta faili rĂŒhma, mille kuuluvus on tema, ning seega vĂ”ib see fail olla teistele kasutajatele, kes kuuluvad sama rĂŒhma, muudetav. Just seda me vajame.

Git hook'i kasutamine

Hooki töökaust on projekti juurkataloog. Hook on tÀidetav fail, mis töötab kasutaja all, kes teeb pushi. Tundes seda, saame ellu viia oma plaanid.

[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

vÔi lihtsalt

vi hooks/post-update

Naaseme kliendimasinasse.

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

Git serveris kontrollime commit'i jÀrel hook post-update skripti tööd

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

— tĂŒhi, kĂ”ik on korras.

Teise arendaja ĂŒhendamine Git'iga

Simuleerime teise arendaja tööd.

Kliendis

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

Samas ajal serveris


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

— jĂ€lle tĂŒhi, kĂ”ik töötab.

Git projekti kustutamine ja projekti laadimine Git serverist

VÔime veel kord veenduda, et kÔik muudatused on salvestatud.

C:gittest>rd /S /Q .
Protsess ei saa faili avada, kuna see on teise protsessi poolt hÔivatud.

— Git projekti kustutamiseks puhastame lihtsalt kausta tĂ€ielikult. Leppige antava veaga, kuna kĂ€esoleva kĂ€su kaudu ei saa jooksvat kausta kustutada, kuid meil on just selline kĂ€itumine vajalik.

C:gittest>dir
 Kaust C:gittest sisu

21.06.2019  08:43              .
21.06.2019  08:43              ..

C:gittest>git clone ssh://dev2@10.1.1.11/var/gitservertest/proj2
Kloonimine kausta 'proj2'...
dev2@10.1.1.11 parool:

C:gittest>cd proj2

C:gittestproj2>dir
 Kaust C:gittestproj2 sisu

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"

LigipÀÀsu jagamine Git'is

NĂŒĂŒd veendume, et ka Git'i kaudu ei saa teine arendaja ligipÀÀsu projekti Proj1, mille kallal ta ei tööta.

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 parool:
fatal: '/var/gitservertest/proj1' ei tundu olevat git-i repository
fatal: ei saanud kaugserverist lugeda.

Palun veenduge, et teil on Ôiged juurdepÀÀsuÔigused
ja et repository eksisteerib.

NĂŒĂŒd lubame juurdepÀÀsu

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

ja pÀrast seda töötab kÔik.

C:gittestproj2>git push origin master
dev2@10.1.1.11 parool:
To ssh://10.1.1.11/var/gitservertest/proj1
 * [uus haru]      master -> master

Lisainformatsioon

Lisaks, kui tekib probleem vaikimisi Ôigustega failide ja kataloogide loomisel, saab CentOS-is kasutada kÀsku

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

Samuti vÔite artiklis kokku puutuda kasulike pisiasjadega:

  • kuidas Linuxis kataloogide puu luua
  • kuidas sed-is edastada aadresside vahemikku teatud reast faili lĂ”puni, st teha sed-is asendus kĂ”ikides ridades peale esimese
  • Kuidas Linuxi find-is otsingu tingimust ĂŒmber pöörata
  • kuidas Linuxi shell-is edastada tsĂŒklile mitu rida ĂŒhe reana
  • kuidas bash-is ĂŒhekordseid jutumĂ€rke ekraanida
  • kuidas Windowsi kĂ€sureas kustutada kataloog koos kogu sisu
  • Kuidas bash mv abil faili ĂŒmber nimetada ilma seda uuesti kirjutamata

AitÀh tÀhelepanu eest.

Allikas: habr.com

Osta usaldusvÀÀrne veebihosting DDoS kaitsega, VPS VDS serverid đŸ”„ Osta usaldusvÀÀrne veebihosting DDoS kaitsega, VPS VDS serverid | ProHoster