ProHoster > Blogi > Haldamine > Mitme kasutaja juurdepääsu korraldamine GIT-serverile

Mitme kasutaja juurdepääsu korraldamine GIT-serverile

Git-serveri installimisel ja seadistamisel tekib küsimus mitme kasutaja juurdepääsu korraldamise kohta mitmele projektile. Uurisin seda probleemi ja leidsin lahenduse, mis vastab kõigile minu nõuetele: lihtne, turvaline, usaldusväärne.

Minu soovid on:

  • iga kasutaja loob ühenduse oma kontoga
  • Sama projektiga saavad töötada mitu kasutajat
  • sama kasutaja saab töötada mitme projektiga
  • igal kasutajal on juurdepääs ainult neile projektidele, millega ta töötab
  • ühenduse loomine peaks olema võimalik käsurea kaudu, mitte ainult mingi veebiliidese kaudu

See oleks ka suurepärane:

  • anda kontrollivatele isikutele kirjutuskaitstud õigused
  • Gitis kasutajaõigusi mugavalt hallata

Ülevaade võimalikest GIT-serverile juurdepääsu võimalustest

Kõigepealt pead teadma, mille vahel valida, seega lühike ülevaade Giti protokollidest.

  • ssh - serverile juurdepääsuks kasutatakse spetsiaalselt loodud kasutajakontot.
    • on kummaline, et Git ei soovita kõikidele hoidlatele juurdepääsuks ühe konto kasutamist. See ei vasta üldse minu nõuetele.
    • Saate kasutada mitut kontot, kuid kuidas saate piirata kasutaja juurdepääsu ainult teatud kataloogidele?
      • Kodukataloogi sulgemine ei sobi, kuna seal on raske teistele kasutajatele kirjutamispääsu korraldada
      • Sümboolsete linkide kasutamine kodukataloogist on samuti keeruline, kuna Git ei tõlgenda neid linkidena.
      • Saate piirata juurdepääsu tõlgile, kuid pole täielikku garantiid, et see alati töötab
        • Tavaliselt saate selliste kasutajate jaoks ühendada oma käsutõlgi, kuid
          • esiteks on see juba mingi raske otsus,
          • ja 2, saab sellest mööda minna.

    Aga võib-olla pole see probleem, et kasutaja saab mingeid käske täita? .. Üldiselt ei saa seda meetodit välistada, kui seda täpselt kasutada. Tuleme selle meetodi juurde hiljem tagasi, kuid praegu kaalume lühidalt ülejäänud alternatiive, võib-olla on midagi lihtsamat.

  • git kohalikku protokolli saab kasutada koos sshfs-iga, saab kasutada mitut kasutajat, kuid see on sisuliselt sama mis eelmisel juhul
  • http – kirjutuskaitstud
  • git on kirjutuskaitstud
  • https on raske paigaldada, vaja on lisatarkvara, mingisugust juhtpaneeli, et kasutaja ligipääsu korraldada... tundub teostatav, aga kuidagi on kõik keeruline.

Ssh-protokolli kasutamine Git-serverile mitme kasutaja juurdepääsu korraldamiseks

Tuleme tagasi ssh-protokolli juurde.

Kuna giti jaoks kasutatakse ssh-juurdepääsu, peavad serveri andmed olema turvalised. Kasutaja, kes loob ühenduse ssh-i kaudu, kasutab Linuxi serveris oma sisselogimist, nii et nad saavad ühenduse luua ssh-kliendi kaudu ja pääseda juurde serveri käsureale.
Sellise juurdepääsu saamise vastu pole täielikku kaitset.

Kuid kasutaja ei tohiks olla huvitatud Linuxi failidest. Sisukas teave salvestatakse ainult giti hoidlas. Seetõttu ei saa te juurdepääsu piirata käsurea kaudu, vaid Linuxi abil keelata kasutajal projektide vaatamine, välja arvatud need, milles ta osaleb.
Linuxi lubade süsteemi kasutamine on ilmne.

Nagu juba mainitud, on ssh-juurdepääsuks võimalik kasutada ainult ühte kontot. See konfiguratsioon on mitme kasutaja jaoks ebaturvaline, kuigi see sisaldub giti soovitatud valikute loendis.

Artikli alguses toodud nõuete rakendamiseks luuakse järgmine kataloogistruktuur koos õiguste ja omanike määramisega:

1) projektikataloogid

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
kus
dir1, dir2, dir3 – projektikataloogid: projekt 1, projekt 2, projekt 3.

proj1:proj1, proj2:proj2, proj3:proj3 on spetsiaalselt loodud Linuxi kasutajad, kes on määratud vastavate projektikataloogide omanikeks.

kõigi kataloogide õigused on seatud numbrile 0770 – täielik juurdepääs omanikule ja tema rühmale ning täielik keeld kõigile teistele.

2) arendajakontod

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

Võtmepunkt on see, et arendajatele määratakse täiendav rühm süsteemi kasutajaid, kellele vastav projekt kuulub. Seda teeb Linuxi serveri administraator ühe käsuga.

Selles näites töötab arendaja 1 projektidega proj1 ja proj2 ning arendaja 2 projektidega proj2 ja proj3.

Kui mõni arendajatest loob ühenduse ssh kaudu käsurea kaudu, ei piisa tema õigustest isegi nende projektide kataloogide sisu vaatamiseks, milles ta ei osale. Ta ei saa seda ise muuta.

Kuna selle põhimõtte aluseks on Linuxi õiguste põhiturvalisus, on see skeem usaldusväärne. Lisaks on skeemi väga lihtne hallata.

Läheme edasi praktika juurde.

Giti hoidlate loomine Linuxi serveris

Me 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

väsinud kirjutamast...

[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

Oleme veendunud, et käsurealt on võimatu pääseda ligi teiste inimeste hoidlatele ja isegi vaadata nende sisu.

[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

Mitme arendaja koostöö Gitis ühe projekti raames

Jääb üks küsimus, et kui üks arendaja tutvustab uut faili, siis teised arendajad seda muuta ei saa, sest tema ise on selle omanik (näiteks dev1), mitte kasutaja, kellele projekt kuulub (näiteks proj1). Kuna meil on serverihoidla, peame ennekõike teadma, kuidas .git kataloog on paigutatud ja kas uusi faile luuakse.

Looge kohalik Giti hoidla ja lükake see Giti serverisse

Liigume edasi klientmasina juurde.

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>

Samal ajal genereeritakse serveris uusi faile ja need kuuluvad tõuke sooritanud kasutajale

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

Kui muudatused laaditakse Giti serverisse, luuakse täiendavaid faile ja katalooge, mis tegelikult kuuluvad üleslaadijale. Aga siis vastab nende failide ja kataloogide grupp ka selle kasutaja põhigrupile ehk siis dev1 kasutajale dev1 grupp ja dev2 kasutajale dev2 grupp (arendaja kasutaja põhigrupi muutmine ei aita, sest siis kuidas töötada mitme projektiga?). Sel juhul ei saa dev2 kasutaja dev1 kasutaja loodud faile muuta ja see on täis funktsionaalsuse rikkumist.

Linux chown – faili omaniku muutmine tavakasutaja poolt

Faili omanik ei saa selle omandiõigust muuta. Kuid ta saab muuta talle kuuluva faili rühma ja seejärel saavad seda faili muuta teised samas rühmas olevad kasutajad. Seda me vajame.

Git Hooki kasutamine

Hooki töökataloog on projekti juurkataloog. hook on käivitatav fail, mis jookseb tõuget tegeva kasutaja all. seda teades saame oma plaanid ellu viia.

[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

kas lihtsalt 

vi hooks/post-update

Läheme tagasi kliendi masina juurde.

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

Giti serveris kontrollige pärast kinnistamist konksu värskendusjärgse skripti tööd 

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

- tühi, kõik on korras.

Teise arendaja ühendamine Gitiga

Simuleerime teise arendaja tööd.

Kliendi peal

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

Ja samal ajal serveris...

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

- jälle tühi, kõik töötab.

Git-projekti kustutamine ja projekti laadimine Git-serverist

Noh, saate veel kord veenduda, et kõik muudatused on salvestatud.

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

- Git-projekti eemaldamiseks tühjendage kataloog täielikult. Leppigem antud veaga, kuna praegust kataloogi pole selle käsuga võimalik kustutada, kuid just seda käitumist vajame.

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"

Gitis juurdepääsu jagamine

Nüüd teeme kindlaks, et teine ​​arendaja ei pääse Giti kaudu ligi Proj1 projektile, mille kallal ta ei tööta.

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üüd lubage juurdepääs

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

ja peale seda kõik töötab.

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

Lisateavet

Lisaks, kui failide ja kataloogide loomisel on probleem vaikelubadega, saate CentOS-is kasutada käsku

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

Samuti võite artiklis komistada väikestele kasulikele asjadele:

  • kuidas linuxis kataloogipuud luua
  • kuidas edastada aadresside vahemik teatud realt sed-is faili lõppu, st teha sed-is asendus kõigil ridadel, välja arvatud esimene rida
  • Kuidas Linuxi otsingus otsingutingimust ümber pöörata
  • kuidas läbida mitu rida läbi ühe voodri linuxi kestas
  • kuidas pääseda bashis üksikutest jutumärkidest
  • kuidas kustutada Windowsi käsurealt kogu sisuga kataloog
  • Kuidas faili bash mv abil ümber nimetada ilma seda ümber kirjutamata

Tänan teid tähelepanu eest.

Allikas: www.habr.com

Lisa kommentaar