ProHoster > Blog > podávání > Organizace víceuživatelského přístupu k serveru GIT

Organizace víceuživatelského přístupu k serveru GIT

Při instalaci a konfiguraci serveru Git vyvstává otázka organizace přístupu několika uživatelů k několika projektům. Provedl jsem průzkum tohoto problému a našel řešení, které splňuje všechny mé požadavky: jednoduché, bezpečné, spolehlivé.

Moje přání jsou:

  • každý uživatel se připojí se svým vlastním účtem
  • Na stejném projektu může pracovat více uživatelů
  • stejný uživatel může pracovat na více projektech
  • každý uživatel má přístup pouze k těm projektům, na kterých pracuje
  • mělo by být možné se připojit přes příkazový řádek, a ne jen přes nějaké webové rozhraní

Také by bylo skvělé:

  • udělovat ovládajícím osobám práva pouze pro čtení
  • pohodlně spravovat uživatelská oprávnění v Gitu

Přehled možných možností přístupu na server GIT

V první řadě je potřeba vědět, z čeho vybírat, takže stručný přehled protokolů Git.

  • ssh - pro přístup k serveru se používá speciálně vytvořený uživatelský účet.
    • je zvláštní, že Git nedoporučuje používat jeden účet pro přístup ke všem úložištím. Tohle vůbec nesplňuje moje požadavky.
    • Můžete použít více účtů, ale jak můžete omezit přístup uživatele pouze k určitým adresářům?
      • Uzavírání do domovského adresáře není vhodné, protože tam je obtížné organizovat přístup pro zápis pro ostatní uživatele
      • Použití symbolických odkazů z domovského adresáře je také složité, protože Git je neinterpretuje jako odkazy.
      • Omezte přístup k tlumočníkovi, dobře, můžete, ale není plná záruka, že to bude vždy fungovat
        • Obecně můžete pro takové uživatele připojit svůj vlastní interpret příkazů, ale
          • za prvé, toto už je nějaké těžké rozhodnutí,
          • a 2, lze jej obejít.

    Možná ale není problém, že uživatel bude moci provádět jakékoli příkazy? .. Obecně nelze tuto metodu vyloučit, pokud zjistíte, jak ji používat. K této metodě se vrátíme později, ale zatím krátce zvážíme zbývající alternativy, možná bude něco jednoduššího.

  • místní protokol git lze použít v kombinaci s sshfs, lze použít více uživatelů, ale je to v podstatě stejné jako v předchozím případě
  • http - pouze pro čtení
  • git je pouze pro čtení
  • https se instaluje složitě, potřebujete další software, nějaký ovládací panel pro organizaci přístupu uživatelů ... vypadá to proveditelně, ale nějak je to všechno složité.

Použití protokolu ssh k organizaci víceuživatelského přístupu k serveru Git

Vraťme se k protokolu ssh.

Vzhledem k tomu, že pro git se používá ssh přístup, musí být data serveru zabezpečená. Uživatel, který se připojuje přes ssh, používá své vlastní přihlášení na linuxovém serveru, takže se může připojit přes ssh klienta a přistupovat k příkazovému řádku serveru.
Neexistuje žádná úplná ochrana proti získání takového přístupu.

O soubory Linuxu by ale uživatel neměl mít zájem. Smysluplné informace jsou uloženy pouze v úložišti git. Proto nemůžete omezit přístup přes příkazový řádek, ale pomocí Linuxu zakázat uživateli prohlížet projekty, s výjimkou těch, kterých se účastní.
Samozřejmostí je použití systému oprávnění Linux.

Jak již bylo zmíněno, pro ssh přístup je možné použít pouze jeden účet. Tato konfigurace je pro několik uživatelů nebezpečná, i když je zahrnuta v seznamu doporučených možností git.

Pro implementaci požadavků uvedených na začátku článku je vytvořena následující adresářová struktura s přiřazením práv a vlastníků:

1) adresáře projektů

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

proj1:proj1, proj2:proj2, proj3:proj3 jsou speciálně vytvoření uživatelé Linuxu, kteří jsou přiřazeni jako vlastníci příslušných adresářů projektu.

práva ke všem adresářům jsou nastavena na 0770 - plný přístup pro vlastníka a jeho skupinu a úplný zákaz pro všechny ostatní.

2) účty pro vývojáře

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

Klíčovým bodem je, že vývojářům je přiřazena další skupina uživatelů systému, kteří vlastní odpovídající projekt. To provede administrátor linuxového serveru jedním příkazem.

V tomto příkladu Vývojář 1 pracuje na projektech proj1 a proj2 a Vývojář 2 pracuje na projektech proj2 a proj3.

Pokud se některý z Vývojářů připojí přes ssh přes příkazový řádek, pak jeho práva nebudou stačit ani na prohlížení obsahu adresářů projektů, kterých se neúčastní. Sám to změnit nemůže.

Protože základem tohoto principu je základní zabezpečení práv Linuxu, je toto schéma spolehlivé. Navíc se schéma velmi snadno ovládá.

Pojďme se cvičit.

Vytváření úložišť Git na serveru Linux

Kontrolujeme 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

unavený z psaní...

[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

Jsme přesvědčeni, že je nemožné přistupovat z příkazového řádku k cizím úložištím a dokonce ani prohlížet jejich 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

Spolupráce v Gitu několika vývojářů na jednom projektu

Jedna otázka zůstává, pokud jeden vývojář zavede nový soubor, tak ho ostatní vývojáři nemohou změnit, protože on sám je jeho vlastníkem (například dev1), a ne uživatel, který vlastní projekt (například proj1). Protože máme serverové úložiště, musíme v první řadě vědět, jak je uspořádán adresář „.git“ a zda se nevytvářejí nové soubory.

Vytvořte místní úložiště Git a odešlete jej na server Git

Přejděme ke klientskému počítači.

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>

Současně se na serveru generují nové soubory, které patří uživateli, který provedl 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]$

Když se změny nahrají na server Git, vytvoří se další soubory a adresáře, které ve skutečnosti vlastní uživatel, který je nahrál. Pak ale skupině těchto souborů a adresářů odpovídá i hlavní skupina tohoto uživatele, tedy skupina dev1 pro uživatele dev1 a skupina dev2 pro uživatele dev2 (změna hlavní skupiny vývojářského uživatele nepomůže, protože pak jak pracovat na více projektech?). V tomto případě uživatel dev2 nebude moci upravovat soubory vytvořené uživatelem dev1, což je plné porušení funkčnosti.

Linux chown - změna vlastníka souboru běžným uživatelem

Vlastník souboru nemůže změnit jeho vlastnictví. Může však změnit skupinu souboru, který mu patří, a tento soubor pak mohou změnit další uživatelé, kteří jsou ve stejné skupině. To je to, co potřebujeme.

Použití Git Hook

Pracovní adresář pro hook je kořenový adresář projektu. hook je spustitelný soubor, který běží pod uživatelem, který provádí push. když to víme, můžeme své plány uskutečnit.

[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

buď jen 

vi hooks/post-update

Vraťme se ke klientskému počítači.

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 serveru Git zkontrolujte po potvrzení práci skriptu po aktualizaci zavěšení 

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

- prázdné, vše v pořádku.

Připojení druhého vývojáře ke Gitu

Pojďme simulovat práci druhého vývojáře.

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 serveru...

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

- opět prázdné, vše funguje.

Odstranění projektu Git a načtení projektu ze serveru Git

Opět se můžete ujistit, že všechny změny byly uloženy.

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

- Chcete-li odstranit projekt Git, jednoduše úplně vymažte adresář. Smiřme se s uvedenou chybou, protože tímto příkazem není možné smazat aktuální adresář, ale přesně toto chování potřebujeme.

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"

Sdílení přístupu v Gitu

Nyní se ujistěte, že druhý vývojář nemůže přistupovat k projektu Proj1 přes Git, na kterém 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.

Nyní povolte přístup

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

a poté vše funguje.

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

Pro více informací

Pokud navíc dojde k problému s výchozími oprávněními při vytváření souborů a adresářů, na CentOS můžete použít příkaz

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

Také v článku můžete narazit na malé užitečné věci:

  • jak vytvořit adresářový strom v linuxu
  • jak předat rozsah adres od určitého řádku na konec souboru v sed, to znamená provést náhradu v sed ve všech řádcích kromě prvního řádku
  • Jak invertovat podmínku vyhledávání v systému Linux find
  • jak projít více řádků přes jeden řádek v linuxovém shellu
  • jak uniknout jednoduchým uvozovkám v bash
  • jak odstranit adresář s veškerým obsahem v příkazovém řádku systému Windows
  • Jak přejmenovat soubor pomocí bash mv bez jeho přepisování

Děkuji vám za pozornost.

Zdroj: www.habr.com

Přidat komentář