ProHoster > Blog > Adminisztráció > Többfelhasználós hozzáférés megszervezése a GIT szerverhez

Többfelhasználós hozzáférés megszervezése a GIT szerverhez

Egy Git szerver telepítésekor és konfigurálásakor felmerül a kérdés, hogy több felhasználó hozzáférését kell-e megszervezni több projekthez. Kutattam a kérdést, és olyan megoldást találtam, amely minden követelményemnek megfelel: egyszerű, biztonságos, megbízható.

A kívánságaim a következők:

  • minden felhasználó a saját fiókjához csatlakozik
  • Egy projekten több felhasználó is dolgozhat
  • ugyanaz a felhasználó több projekten is dolgozhat
  • minden felhasználó csak azokhoz a projektekhez férhet hozzá, amelyeken dolgozik
  • Lehetővé kell tenni a csatlakozást parancssoron keresztül, és nem csak valamilyen webes felületen keresztül

Az is szuper lenne:

  • csak olvasási engedélyt ad az irányító személyeknek
  • Kényelmesen kezelheti a felhasználói hozzáférési jogokat a Gitben

A GIT-szerver elérési lehetőségeinek áttekintése

Először is tudnod kell, hogy miből válassz, ezért itt egy gyors áttekintés a Git protokollokról.

  • ssh - egy speciálisan létrehozott felhasználói fiókot használnak a szerver eléréséhez.
    • Furcsa, hogy a Git nem zárja ki ajánlásai közül egy fiók használatát az összes adattárhoz való hozzáféréshez. Ez egyáltalán nem felel meg a követelményeimnek.
    • Több fiókot is használhat, de hogyan korlátozhatja a felhasználói hozzáférést csak bizonyos könyvtárakra?
      • A saját könyvtárba való bezárás nem megfelelő, mert ott nehéz megszervezni az írási hozzáférést a többi felhasználó számára
      • A saját könyvtárból származó szimbolikus hivatkozások használata azért is nehéz, mert a Git nem értelmezi őket hivatkozásként
      • Lehetséges korlátozni a tolmácshoz való hozzáférést, de nincs teljes garancia arra, hogy mindig működni fog
        • Általában csatlakoztathatja saját parancsértelmezőjét az ilyen felhasználókhoz, de
          • először is, ez már egyfajta nehéz döntés,
          • másodszor pedig ez megkerülhető.

    De talán az sem baj, hogy a felhasználó képes lesz bármilyen parancsot végrehajtani?.. Általánosságban elmondható, hogy ez a módszer nem zárható ki, ha pontosan kitaláljuk, hogyan kell használni. Erre a módszerre később még visszatérünk, de most röviden átgondoljuk a többi alternatívát, talán lesz valami egyszerűbb.

  • A git helyi protokoll használható sshfs-el kombinálva, több felhasználó is használható, de lényegében ugyanaz, mint az előző eset
  • http – csak olvasható
  • A git csak olvasható
  • https - nehéz telepíteni, kell hozzá kiegészítő szoftver, valami vezérlőpult a felhasználói hozzáférés megszervezéséhez... kivitelezhetőnek tűnik, de valahogy minden bonyolult.

Az ssh protokoll használata a többfelhasználós hozzáférés megszervezéséhez a Git szerverhez

Térjünk vissza az ssh protokollhoz.

Mivel ssh hozzáférést használ a githez, gondoskodnia kell a kiszolgáló adatainak biztonságáról. Az ssh-n keresztül csatlakozó felhasználó a saját bejelentkezési adatait használja a Linux szerveren, így az ssh-kliensen keresztül csatlakozhat, és elérheti a szerver parancssorát.
Nincs teljes védelem az ilyen hozzáférés ellen.

De a felhasználót ne érdekeljék a Linux-fájlok. A jelentős információk csak a git tárolóban tárolódnak. Ezért lehetőség van arra, hogy ne a parancssoron keresztül korlátozzuk a hozzáférést, hanem Linux-eszközökkel tiltsuk meg a felhasználó számára a projektek megtekintését, kivéve azokat, amelyekben részt vesz.
A kézenfekvő választás a Linux engedélyrendszer használata.

Mint már említettük, csak egy fiók használható az ssh-hozzáféréshez. Ez a konfiguráció több felhasználó számára nem biztonságos, bár szerepel az ajánlott git-beállítások listáján.

A cikk elején megadott követelmények megvalósításához a következő címtárszerkezet jön létre a jogok és tulajdonosok hozzárendelésével:

1) projektkönyvtárak

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
ahol
dir1, dir2, dir3 - projektkönyvtárak: 1. projekt, 2. projekt, 3. projekt.

A proj1:proj1, proj2:proj2, proj3:proj3 speciálisan létrehozott Linux-felhasználók, akik a megfelelő projektkönyvtárak tulajdonosaiként vannak hozzárendelve.

az összes könyvtár engedélye 0770 - teljes hozzáférés a tulajdonos és csoportja számára, és teljes kitiltás mindenki más számára.

2) fejlesztői fiókok

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

A lényeg az, hogy a fejlesztők hozzá vannak rendelve a megfelelő projekt rendszerfelhasználóinak egy további csoportjához. Ezt a Linux szerver rendszergazdája egy paranccsal végzi el.

Ebben a példában a „Fejlesztő 1” a proj1 és a proj2 projekteken, a „Developer 2” pedig a proj2 és a proj3 projekteken dolgozik.

Ha a Fejlesztők bármelyike ​​ssh-n keresztül csatlakozik a parancssoron keresztül, akkor a jogai még olyan projektkönyvtárak tartalmának megtekintéséhez sem lesznek elegendőek, amelyekben nem vesznek részt. Ezen ő maga nem tud változtatni.

Mivel ennek az elvnek az alapja a Linux jogok alapvető biztonsága, ez a séma megbízható. Ezenkívül a rendszer nagyon egyszerűen kezelhető.

Menjünk a gyakorlatba.

Git-tárolók létrehozása Linux-kiszolgálón

Ellenőrizzük.

[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

elegem van a kézzel gépelésből...

[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

Meggyőződésünk, hogy a parancssorból lehetetlen hozzáférni mások adattáraihoz, és még a tartalmát sem lehet megtekinteni.

[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

Együttműködhet több fejlesztővel ugyanazon a projekten a Gitben

Egy kérdés marad, ha egy fejlesztő bevezet egy új fájlt, akkor azt a többi fejlesztő nem tudja megváltoztatni, mert ő maga a tulajdonosa (például dev1), és nem a projekt felhasználó tulajdonosa (például proj1). Mivel szerveroldali tárolóval rendelkezünk, mindenekelőtt tudnunk kell, hogyan épül fel a „.git” könyvtár, és hogy jönnek-e létre új fájlok.

Helyi Git-lerakat létrehozása és leküldése a Git-kiszolgálóra

Térjünk át a kliens gépre.

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>

Ezzel egyidejűleg új fájlok jönnek létre a szerveren, és azok a leküldést végrehajtó felhasználóhoz tartoznak

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

Amikor feltölti a módosításokat a Git-kiszolgálóra, további fájlok és könyvtárak jönnek létre, amelyek tulajdonosa valójában a feltöltést végző felhasználó. De akkor ezeknek a fájloknak és könyvtáraknak a csoportja megfelel a felhasználó főcsoportjának is, vagyis a dev1 csoportnak a dev1 felhasználónak és a dev2 csoportnak a dev2 felhasználónak (a fejlesztő felhasználó főcsoportjának megváltoztatása nem segít, mert akkor hogyan lehet több projekten dolgozni?). Ebben az esetben a dev2 felhasználó nem tudja módosítani a dev1 felhasználó által létrehozott fájlokat, ami a funkcionalitás meghibásodásához vezethet.

Linux chown - egy fájl tulajdonosának megváltoztatása egy normál felhasználó által

A fájl tulajdonosa nem változtathatja meg a tulajdonjogát. De módosíthatja a hozzá tartozó fájl csoportját, majd ezt a fájlt más, ugyanabban a csoportban lévő felhasználók módosíthatják. Erre van szükségünk.

Git hook használata

A hook munkakönyvtára a projekt gyökérkönyvtára. A hook egy végrehajtható fájl, amely a push felhasználó alatt fut. Ennek ismeretében megvalósíthatjuk terveinket.

[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

akár csak 

vi hooks/post-update

Térjünk vissza a kliens géphez.

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

A Git szerveren ellenőrizzük a hook post-update script működését a véglegesítés után 

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

- üres, minden rendben.

Egy második fejlesztő csatlakoztatása a Gitben

Szimuláljuk a második fejlesztő munkáját.

Az ügyfélen

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

És ugyanakkor a szerveren...

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

- újra üres, minden működik.

Egy Git-projekt törlése és a projekt letöltése a Git-kiszolgálóról

Nos, ismét megbizonyosodhat arról, hogy az összes módosítást elmentette.

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

- Git-projekt törléséhez egyszerűen törölje teljesen a könyvtárat. Tűrjük meg a keletkező hibát, mivel ezzel a paranccsal nem lehet törölni az aktuális könyvtárat, de pontosan erre van szükségünk.

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"

Hozzáférés megosztása a Gitben

Most pedig győződjünk meg arról, hogy a második fejlesztő még a Giten keresztül sem férhet hozzá a Proj1 projekthez, amelyen nem dolgozik.

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.

Most engedélyezzük a hozzáférést

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

és utána minden működik.

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

További információ

Ezenkívül, ha probléma van az alapértelmezett engedélyekkel a fájlok és könyvtárak létrehozásakor, a CentOS-ben használhatja a parancsot

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

A cikkben apró hasznos dolgokra is bukkanhat:

  • hogyan készítsünk könyvtárfát Linuxban
  • hogyan lehet egy címtartományt sed-ben átadni egy bizonyos sorból a fájl végére, azaz cserélni a sed-ben minden sorban, kivéve az első sort
  • Hogyan lehet megfordítani a keresési feltételt a Linux keresőben
  • Hogyan lehet több sort átadni egy ciklusnak egy soros vonallal a Linux shellben
  • Hogyan lehet elkerülni az egyetlen idézőjeleket a bash-ban
  • hogyan lehet törölni egy könyvtárat annak teljes tartalmával a Windows parancssorban
  • Hogyan lehet a bash mv-vel átnevezni egy fájlt anélkül, hogy újra át kellene írni

Köszönöm a figyelmet.

Forrás: will.com

Hozzászólás