ProHoster > Blog > Administrácia > Organizácia prístupu viacerých používateľov na server GIT

Organizácia prístupu viacerých používateľov na server GIT

Pri inštalácii a konfigurácii servera Git vyvstáva otázka organizácie prístupu viacerých používateľov k niekoľkým projektom. Skúmal som problém a našiel som riešenie, ktoré spĺňalo všetky moje požiadavky: jednoduché, bezpečné, spoľahlivé.

Moje priania sú:

  • každý používateľ sa pripojí k svojmu účtu
  • Na jednom projekte môže pracovať viacero používateľov
  • ten istý používateľ môže pracovať na viacerých projektoch
  • každý užívateľ má prístup len k tým projektom, na ktorých pracuje
  • Malo by byť možné pripojiť sa cez príkazový riadok, a nie len cez nejaké webové rozhranie

Tiež by bolo skvelé:

  • udeľovať kontrolujúcim osobám povolenia len na čítanie
  • Pohodlne spravujte prístupové práva používateľov v Git

Prehľad možných možností prístupu na server GIT

V prvom rade musíte vedieť, z čoho vyberať, preto tu je rýchly prehľad protokolov Git.

  • ssh - na prístup k serveru sa používa špeciálne vytvorený používateľský účet.
    • Je zvláštne, že Git nevylučuje zo svojich odporúčaní používanie jedného účtu na prístup ku všetkým úložiskám. Toto vôbec nespĺňa moje požiadavky.
    • Môžete použiť viacero účtov, ale ako môžete obmedziť prístup používateľov iba k určitým adresárom?
      • Zatvorenie do domovského adresára nie je vhodné, pretože je ťažké organizovať tam prístup na zápis pre iných používateľov
      • Používanie symbolických odkazov z vášho domovského adresára je tiež ťažké, pretože Git ich neinterpretuje ako odkazy
      • Prístup k tlmočníkovi je možné obmedziť, ale nie je možné zaručiť, že bude vždy fungovať
        • Vo všeobecnosti môžete pre takýchto používateľov pripojiť svoj vlastný tlmočník príkazov, ale
          • po prvé, toto je už nejaký druh ťažkého rozhodnutia,
          • a po druhé, dá sa to obísť.

    Ale možno nie je problém, že používateľ bude môcť vykonávať akékoľvek príkazy?. Vo všeobecnosti sa tento spôsob nedá vylúčiť, ak presne zistíte, ako ho používať. K tejto metóde sa vrátime neskôr, ale zatiaľ stručne zvážime iné alternatívy, možno bude niečo jednoduchšie.

  • Lokálny protokol git je možné použiť v kombinácii s sshfs, možno použiť viacerých používateľov, ale v podstate to isté ako v predchádzajúcom prípade
  • http - len na čítanie
  • git je len na čítanie
  • https - náročná inštalácia, potrebujete dodatočný softvér, nejaký ovládací panel na organizáciu prístupu používateľov... vyzerá to uskutočniteľné, ale akosi je všetko komplikované.

Používanie protokolu ssh na organizáciu prístupu viacerých používateľov k serveru Git

Vráťme sa k protokolu ssh.

Keďže pre git používate ssh prístup, musíte zaistiť bezpečnosť údajov servera. Používateľ, ktorý sa pripája cez ssh, používa svoje vlastné prihlásenie na serveri Linux, takže sa môže pripojiť cez klienta ssh a získať prístup k príkazovému riadku servera.
Proti takémuto prístupu neexistuje úplná ochrana.

Používateľa by ale súbory Linuxu nemali zaujímať. Dôležité informácie sú uložené iba v úložisku git. Preto je možné neobmedzovať prístup cez príkazový riadok, ale pomocou nástrojov Linuxu zakázať používateľovi prezeranie projektov, s výnimkou tých, na ktorých sa podieľa.
Jasnou voľbou je použiť systém povolení Linux.

Ako už bolo spomenuté, na ssh prístup je možné použiť len jeden účet. Táto konfigurácia je pre viacerých používateľov nebezpečná, hoci je zahrnutá v zozname odporúčaných možností git.

Na implementáciu požiadaviek uvedených na začiatku článku je vytvorená nasledujúca adresárová štruktúra s pridelením práv a vlastníkov:

1) adresáre projektov

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
kde
dir1, dir2, dir3 - adresáre projektov: projekt 1, projekt 2, projekt 3.

proj1:proj1, proj2:proj2, proj3:proj3 sú špeciálne vytvorení používatelia Linuxu, ktorí sú priradení ako vlastníci príslušných adresárov projektov.

povolenia pre všetky adresáre sú nastavené na 0770 - úplný prístup pre vlastníka a jeho skupinu a úplný zákaz pre všetkých ostatných.

2) účty vývojárov

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

Kľúčovým bodom je, že vývojárom je priradená ďalšia skupina vlastníkov systémových používateľov príslušného projektu. Toto vykoná správca servera Linux jedným príkazom.

V tomto príklade „Vývojár 1“ pracuje na projektoch proj1 a proj2 a „Vývojár 2“ pracuje na projektoch proj2 a proj3.

Ak sa ktorýkoľvek z vývojárov pripojí cez ssh cez príkazový riadok, jeho práva nebudú postačovať ani na prezeranie obsahu projektových adresárov, na ktorých sa nezúčastňuje. Sám to nemôže zmeniť.

Keďže základom tohto princípu je základné zabezpečenie práv Linuxu, je táto schéma spoľahlivá. Okrem toho sa schéma veľmi ľahko spravuje.

Pokračujme v praxi.

Vytváranie archívov Git na serveri Linux

Skontrolujme to.

[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

Už ma nebaví písať rukou...

[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

Sme presvedčení, že nie je možné pristupovať k úložiskám iných ľudí z príkazového riadku a dokonca ani prezerať ich obsah.

[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

Spolupracujte s viacerými vývojármi na rovnakom projekte v Git

Otázkou zostáva, ak jeden vývojár zavedie nový súbor, potom ho ostatní vývojári nemôžu zmeniť, pretože on sám je jeho vlastníkom (napríklad dev1), a nie užívateľským vlastníkom projektu (napríklad proj1). Keďže máme úložisko na strane servera, v prvom rade potrebujeme vedieť, ako je štruktúrovaný adresár „.git“ a či sa vytvárajú nové súbory.

Vytvorenie lokálneho úložiska Git a odoslanie na server Git

Prejdime ku klientskemu stroju.

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>

Súčasne sa na serveri vytvárajú nové súbory, ktoré patria používateľovi, ktorý vykonal 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]$

Keď odovzdáte zmeny na server Git, vytvoria sa ďalšie súbory a adresáre a ich vlastníkom je v skutočnosti používateľ, ktorý vykoná odovzdanie. Potom však skupina týchto súborov a adresárov zodpovedá aj hlavnej skupine tohto používateľa, teda skupine dev1 pre používateľa dev1 a skupine dev2 pre používateľa dev2 (zmena hlavnej skupiny vývojára nepomôže, pretože ako potom môžete pracovať na viacerých projektoch?). V tomto prípade používateľ dev2 nebude môcť meniť súbory vytvorené používateľom dev1, čo by mohlo viesť k poruche funkčnosti.

Linux chown - zmena vlastníka súboru bežným používateľom

Vlastník súboru nemôže zmeniť jeho vlastníctvo. Môže však zmeniť skupinu súboru, ktorý mu patrí, a potom tento súbor môžu upraviť iní používatelia, ktorí sú v rovnakej skupine. To je to, čo potrebujeme.

Pomocou Git hook

Pracovný adresár pre hook je koreňový adresár projektu. hook je spustiteľný súbor, ktorý beží pod používateľom, ktorý vykonáva push. Keď to vieme, môžeme realizovať naše plány.

[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

alebo len tak 

vi hooks/post-update

Vráťme sa ku klientskemu 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 serveri Git kontrolujeme fungovanie skriptu po aktualizácii háku po odovzdaní 

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

- prázdno, všetko je v poriadku.

Pripojenie druhého vývojára v Git

Poďme simulovať prácu druhého vývojára.

Na klientovi

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

A zároveň na serveri...

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

— opäť prázdne, všetko funguje.

Odstránenie projektu Git a stiahnutie projektu zo servera Git

Opäť sa môžete uistiť, že všetky zmeny boli uložené.

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

— ak chcete odstrániť projekt Git, jednoducho úplne vymažte adresár. Zmierme sa s chybou, ktorá sa vygeneruje, keďže pomocou tohto príkazu nie je možné vymazať aktuálny adresár, ale presne toto správanie potrebujeme.

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"

Zdieľanie prístupu v Git

Teraz sa uistite, že aj cez Git druhý vývojár nemôže pristupovať k projektu Proj1, na ktorom nepracuje.

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.

Teraz povolíme prístup

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

a potom vsetko funguje.

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

Pre viac informácií

Okrem toho, ak sa vyskytne problém s predvolenými povoleniami pri vytváraní súborov a adresárov, v CentOS môžete použiť príkaz

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

Aj v článku môžete naraziť na malé užitočné veci:

  • ako vytvoriť adresárový strom v systéme Linux
  • ako odovzdať rozsah adries v sed z určitého riadku na koniec súboru, to znamená urobiť náhradu v sed vo všetkých riadkoch okrem prvého riadku
  • Ako invertovať podmienku vyhľadávania v systéme Linux find
  • Ako odovzdať viacero riadkov do slučky pomocou jedného riadku v prostredí Linuxu
  • Ako uniknúť jednoduchým úvodzovkám v bash
  • ako odstrániť adresár s celým jeho obsahom v príkazovom riadku systému Windows
  • Ako použiť bash mv na premenovanie súboru bez jeho opätovného prepisovania

Ďakujem vám za pozornosť.

Zdroj: hab.com

Pridať komentár