ProHoster > Blog > Uprava > Organizacija večuporabniškega dostopa do strežnika GIT

Organizacija večuporabniškega dostopa do strežnika GIT

Pri nameščanju in konfiguriranju strežnika Git se postavlja vprašanje o organizaciji dostopa za več uporabnikov do več projektov. Raziskal sem težavo in našel rešitev, ki je izpolnila vse moje zahteve: preprosto, varno, zanesljivo.

Moje želje so:

  • vsak uporabnik se poveže s svojim računom
  • Na enem projektu lahko dela več uporabnikov
  • isti uporabnik lahko dela na več projektih
  • vsak uporabnik ima dostop samo do tistih projektov, na katerih dela
  • Povezava naj bi bila mogoča prek ukazne vrstice in ne le prek nekakšnega spletnega vmesnika

Super bi bilo tudi:

  • dodeli dovoljenja samo za branje nadzornim osebam
  • Priročno upravljajte pravice dostopa uporabnikov v Gitu

Pregled možnih možnosti dostopa do strežnika GIT

Najprej morate vedeti, med čim lahko izberete, zato je tukaj kratek pregled protokolov Git.

  • ssh - za dostop do strežnika se uporablja posebej ustvarjen uporabniški račun.
    • Nenavadno je, da Git iz svojih priporočil ne izključuje uporabe enega računa za dostop do vseh skladišč. To nikakor ne ustreza mojim zahtevam.
    • Uporabite lahko več računov, toda kako lahko omejite uporabniški dostop samo na določene imenike?
      • Zapiranje v domači imenik ni primerno, ker je tam težko organizirati pisanje za druge uporabnike
      • Uporaba simbolnih povezav iz domačega imenika je prav tako težavna, ker jih Git ne interpretira kot povezave
      • Dostop do tolmača je mogoče omejiti, vendar ni popolnega zagotovila, da bo vedno deloval
        • Na splošno lahko za take uporabnike povežete lastnega tolmača ukazov, vendar
          • prvič, to je že neka težka odločitev,
          • in drugič, to je mogoče zaobiti.

    Morda pa ni problem, da bo uporabnik lahko izvedel vse ukaze?.. Na splošno te metode ni mogoče izključiti, če natančno ugotovite, kako jo uporabljati. K tej metodi se bomo vrnili pozneje, zdaj pa bomo na kratko razmislili o drugih alternativah, morda bo nekaj preprostejšega.

  • Lokalni protokol git se lahko uporablja v kombinaciji s sshfs, lahko se uporablja več uporabnikov, vendar v bistvu enako kot prejšnji primer
  • http - samo za branje
  • git je samo za branje
  • https - težko namestiti, potrebujete dodatno programsko opremo, nekakšno nadzorno ploščo za organizacijo dostopa uporabnikov ... izgleda izvedljivo, vendar je nekako vse skupaj zapleteno.

Uporaba protokola ssh za organiziranje večuporabniškega dostopa do strežnika Git

Vrnimo se k protokolu ssh.

Ker za git uporabljate dostop ssh, morate zagotoviti varnost podatkov strežnika. Uporabnik, ki se poveže prek ssh, uporablja lastno prijavo na strežniku Linux, tako da se lahko poveže prek odjemalca ssh in dostopa do ukazne vrstice strežnika.
Popolne zaščite pred takim dostopom ni.

Vendar uporabnika ne bi smele zanimati datoteke Linuxa. Pomembne informacije so shranjene samo v repozitoriju git. Zato je mogoče dostopa ne omejiti prek ukazne vrstice, temveč z orodji Linux uporabniku prepovedati ogled projektov, razen tistih, v katerih sodeluje.
Očitna izbira je uporaba sistema dovoljenj Linux.

Kot že omenjeno, je možno za ssh dostop uporabiti le en račun. Ta konfiguracija ni varna za več uporabnikov, čeprav je vključena na seznam priporočenih možnosti git.

Za izvajanje zahtev, navedenih na začetku članka, je ustvarjena naslednja struktura imenika z dodelitvijo pravic in lastnikov:

1) imeniki projektov

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
če
dir1, dir2, dir3 - imeniki projektov: projekt 1, projekt 2, projekt 3.

proj1:proj1, proj2:proj2, proj3:proj3 so posebej ustvarjeni uporabniki Linuxa, ki so dodeljeni kot lastniki ustreznih projektnih imenikov.

dovoljenja za vse imenike so nastavljena na 0770 - popoln dostop za lastnika in njegovo skupino ter popolna prepoved za vse ostale.

2) računi razvijalcev

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

Ključno je, da je razvijalcem dodeljena dodatna skupina lastnikov sistemskih uporabnikov ustreznega projekta. To naredi skrbnik strežnika Linux z enim ukazom.

V tem primeru "Razvijalec 1" dela na projektih proj1 in proj2, "Razvijalec 2" pa na projektih proj2 in proj3.

Če se kateri od razvijalcev poveže prek ssh prek ukazne vrstice, potem njegove pravice ne bodo zadostovale niti za ogled vsebine projektnih imenikov, v katerih ne sodelujejo. Sam tega ne more spremeniti.

Ker je osnova tega načela osnovna varnost pravic Linuxa, je ta shema zanesljiva. Poleg tega je shema zelo enostavna za upravljanje.

Vstopimo v prakso.

Ustvarjanje repozitorijev Git na strežniku Linux

Preverimo.

[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

Utrujen sem od ročnega tipkanja ...

[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

Prepričani smo, da je iz ukazne vrstice nemogoče dostopati do repozitorijev drugih ljudi in si celo ogledati njihovo vsebino.

[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

Sodelujte z več razvijalci pri istem projektu v Gitu

Ostaja eno vprašanje, če en razvijalec uvede novo datoteko, potem je drugi razvijalci ne morejo spremeniti, ker je sam njen lastnik (na primer dev1) in ne lastnik uporabnika projekta (na primer proj1). Ker imamo repozitorij na strani strežnika, moramo najprej vedeti, kako je strukturiran imenik ».git« in ali so ustvarjene nove datoteke.

Ustvarjanje lokalnega repozitorija Git in potiskanje na strežnik Git

Pojdimo na odjemalski stroj.

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>

Hkrati se na strežniku ustvarijo nove datoteke, ki pripadajo uporabniku, ki je izvedel 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 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]$

Ko naložite spremembe na strežnik Git, se ustvarijo dodatne datoteke in imeniki, njihov lastnik pa je dejansko uporabnik, ki izvede nalaganje. Toda potem skupina teh datotek in imenikov ustreza tudi glavni skupini tega uporabnika, to je skupini dev1 za uporabnika dev1 in skupini dev2 za uporabnika dev2 (spreminjanje glavne skupine uporabnika razvijalca ne bo pomagalo, ker kako potem lahko delaš na več projektih?). V tem primeru uporabnik dev2 ne bo mogel spreminjati datotek, ki jih je ustvaril uporabnik dev1, kar bi lahko povzročilo okvaro funkcionalnosti.

Linux chown - zamenjava lastnika datoteke s strani običajnega uporabnika

Lastnik datoteke ne more spremeniti njenega lastništva. Lahko pa spremeni skupino datoteke, ki mu pripada, nato pa lahko to datoteko spreminjajo drugi uporabniki, ki so v isti skupini. To je tisto, kar potrebujemo.

Uporaba kljuke Git

Delovni imenik za hook je korenski imenik projekta. hook je izvršljiva datoteka, ki se izvaja pod uporabnikom, ki izvaja potiskanje. Če to vemo, lahko uresničimo svoje načrte.

[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

ali samo 

vi hooks/post-update

Vrnimo se k odjemalskemu stroju.

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

Na strežniku Git preverimo delovanje skripta po posodobitvi kljuke po potrditvi 

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

- prazno, vse je v redu.

Povezovanje drugega razvijalca v Git

Simulirajmo delo drugega razvijalca.

Na stranko

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

In hkrati na strežniku...

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

— spet prazno, vse deluje.

Brisanje projekta Git in prenos projekta s strežnika Git

No, še enkrat se lahko prepričate, da so bile vse spremembe shranjene.

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

— če želite izbrisati projekt Git, preprosto popolnoma počistite imenik. Sprijaznimo se z ustvarjeno napako, saj je s tem ukazom nemogoče izbrisati trenutni imenik, vendar potrebujemo točno to vedenje.

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"

Deljenje dostopa v Gitu

Zdaj pa poskrbimo, da tudi prek Gita drugi razvijalec ne more dostopati do projekta Proj1, na katerem ne dela.

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.

Zdaj dovolimo dostop

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

in potem vse deluje.

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

Za več informacij,

Poleg tega, če obstaja težava s privzetimi dovoljenji pri ustvarjanju datotek in imenikov, lahko v CentOS uporabite ukaz

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

Tudi v članku lahko naletite na majhne uporabne stvari:

  • kako zgraditi drevo imenikov v Linuxu
  • kako prenesti vrsto naslovov v sed iz določene vrstice na konec datoteke, to je narediti zamenjavo v sed v vseh vrsticah razen v prvi vrstici
  • Kako obrniti iskalni pogoj v Linux find
  • Kako prenesti več vrstic v zanko z enovrstičnico v lupini Linux
  • Kako se izogniti enojnim narekovajem v bashu
  • kako izbrisati imenik z vso njegovo vsebino v ukazni vrstici windows
  • Kako uporabiti bash mv za preimenovanje datoteke, ne da bi jo znova prepisali

Hvala za vašo pozornost.

Vir: www.habr.com

Dodaj komentar