🥇A többfelhasználós hozzáférés megszervezése a GIT szerveren

A Git-szerver telepítése és konfigurálása során felmerül a kérdés, hogyan lehetne több felhasználó hozzáférését biztosítani több projekthez. Kutatást végeztem a témában, és megtaláltam egy megoldást, amely minden igényemet kielégíti: egyszerű, biztonságos és megbízható.

Az elvárásaim a következők:

mindegyik felhasználó a saját fiókjával csatlakozik
több felhasználó dolgozhat egy projekten
ugyanaz a felhasználó több projekten is dolgozhat
minden felhasználónak csak azokhoz a projektekhez kell hozzáférnie, amelyekben dolgozik
lehetőség kell legyen parancssoron keresztüli csatlakozásra is, nem csak valamilyen webes felületen keresztül

Emellett jó lenne:

csak olvasási jogokat biztosítani a felügyeleti személyeknek
kényelmesen adminisztrálni a felhasználói hozzáférési jogokat a Git-ben

A GIT szerverhez való hozzáférési lehetőségek áttekintése

Mindenekelőtt tudni kell, miből lehet választani, ezért egy rövid áttekintést adok a Git protokollokról.

ssh - a szerverhez való hozzáféréshez egy külön létrehozott felhasználói fiókot használnak.
- Furcsa, hogy a Git nem zárja ki az összes tárolóhoz való hozzáféréshez egyetlen fiók használatát. Ez semmilyen módon nem felel meg az igényeimnek.
- Több fiókot lehet használni, de hogyan lehet korlátozni a felhasználó hozzáférését csak meghatározott könyvtárakra?
  - A felhasználó otthoni könyvtárba való korlátozása nem megfelelő, mert nehéz megszervezni a más felhasználók írási hozzáférését abba.
  - A szimbolikus linkek használata az otthoni könyvtárból szintén nehéz, mert a Git nem értelmezi ezeket linkként.
  - A hozzáférés korlátozása az interpreterhez, nos, ezt meg lehet oldani, de nincs teljes garancia arra, hogy ez mindig működni fog.
    - A felhasználók számára saját parancsértelmező csatlakoztatása is lehetséges, de
      - először is, ez már egy bonyolult megoldás,
      - másodszor, ezt ki lehet játszani.
De talán nem probléma, hogy a felhasználó bármilyen parancsot végrehajthat? Összességében nem zárhatjuk ki ezt a módszert, ha kitaláljuk, hogyan lehet pontosan használni. Térjünk vissza ehhez a módszerhez később, addig nézzük át a többi alternatívát, hátha találunk valami egyszerűbbet.
A git local protocol can be used in conjunction with sshfs, allowing multiple users; however, it is essentially the same as the previous case.
http — read-only
git — read-only
https — difficult to set up, requiring additional software of some kind vezérlőpanel for organizing user access... it appears implementable, but everything seems complicated.

Using ssh protocol to organize multi-user access to the Git server

Let's return to the ssh protocol.

Since ssh access is used for git, it is necessary to ensure the security of the server data. A user connecting via ssh uses their own login on szerveren Linux, so they can connect through an ssh client and gain access to the server's command line.
There is no complete protection against such access.

However, users should not be concerned with Linux files. Significant information is stored only in the git repository. Therefore, access through the command line can be unrestricted, but by using Linux methods, users can be prevented from viewing projects, except for those they participate in.
It is obviously necessary to use the Linux access rights system.

As mentioned earlier, it is possible to use only one account for ssh access. This configuration is unsafe for multiple users, although this method is included in the list of recommended git options.

To implement the requirements outlined at the beginning of the article, the following directory structure is created with designated rights and owners:

1) project directories

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
…
ahol
dir1, dir2, dir3 — project directories: project 1, project 2, project 3.

proj1:proj1, proj2:proj2, proj3:proj3 — specially created Linux users assigned as owners of the corresponding project directories.

Permissions for all directories are set to 0770 — full access for the owner and their group, and total prohibition for all others.

2) developer accounts

Developer 1: dev1:dev1,proj1,proj2
Developer 2: dev2:dev2,proj2,proj3

The key point is that developers are assigned an additional group of the system user who owns the respective project. This is done by the Linux server administrator with a single command.

Ebben a példában az 'Első Fejlesztő' a proj1 és proj2 projekten dolgozik, míg a 'Második Fejlesztő' a proj2 és proj3 projekteken.

Ha bármelyik Fejlesztő SSH-n keresztül csatlakozik a parancssoron, akkor nem lesz elegendő joga még a projektek tartalmának megtekintésére sem, amelyekben nem vesz részt. Ezen nem tud változtatni.

Mivel ennek az elvnek az alapja a Linux jogok alapvető biztonsága, ez a rendszer megbízható. Ezen kívül a kezelése is nagyon egyszerű.

Lépjünk a gyakorlatra.

Git tárolók létrehozása Linux szerveren

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

unom, hogy kézzel kell beírni…

[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

Biztosítjuk, hogy a parancssorból nem lehet hozzáférni mások tárolóihoz, és még a tartalmukat sem lehet megnézni.

[dev1@server ~]$ cd /var/gitservertest/proj3
-bash: cd: /var/gitservertest/proj3: Hozzáférés megtagadva
[dev1@server ~]$ ls /var/gitservertest/proj3
ls: cannot open directory /var/gitservertest/proj3: Hozzáférés megtagadva

Több fejlesztő együttműködése Git-en egy projekten

Egy kérdés marad, ha egy fejlesztő új fájlt hoz létre, akkor a többi fejlesztő nem módosíthatja azt, mert ő a tulajdonosa (például dev1), nem pedig a projekt felhasználói tulajdonosa (például proj1). Mivel szerver oldali tárolónk van, először is tudni kell, hogyan van felépítve a '.git' könyvtár és hogyan jönnek létre az új fájlok.

Helyi Git tároló létrehozása és push a Git szerverre

Lépjünk át az ügyfél gépére.

Microsoft Windows [Version 6.1.7601]
(c) Microsoft Corporation, 2009. Minden jog fenntartva.

C:gittest>git init .
Üres Git tároló inicializálva a C:\/gittest\/ .git\/ -ben.

C:gittest>echo "test dev1 to proj2" > test1.txt

C:gittest>git add .

C:gittest>git status
A master ágon
Még nincsenek elkötelezett változások
Elkötelezésre váró változások:
  (használja a "git rm --cached <file>..." parancsot a visszavonáshoz)
        új fájl:   test1.txt

C:gittest>git commit -am "új teszt fájl hozzáadva"
[master (root-commit) a7ac614] új teszt fájl hozzáadva
 1 fájl módosult, 1 beszúrás(+)
 új mód: 100644 test1.txt
 
C:gittest>git remote add origin "ssh:\/\/dev1@10.1.1.11\/var\/gitservertest\/proj2"

C:gittest>git push origin master
dev1:dev1@10.1.1.11 jelszava:
Objektumok számlálása: 3, kész.
Objektumok írása: 100% (3\/3), 243 bájt | 243.00 KiB\/s, kész.
Összesen 3 (delta 0), újrahasználva 0 (delta 0)
A ssh:\/\/10.1.1.11\/var\/gitservertest\/proj2 címre
 * [új ágon]      master -> master

C:gittest>

Ebben az időben a szerveren új fájlok keletkeznek, és ezek a fájlok annak a felhasználónak a tulajdonában állnak, aki végrehajtotta a push-t.

[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 könyvtár, 18 fájl
[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]$

A Git változtatások szerverre történő feltöltésekor további fájlok és könyvtárak keletkeznek, amelyek valóban azokat a felhasználókat illetik, akik végrehajtják a feltöltést. Azonban ezeknek a fájloknak és könyvtáraknak a csoportja is megfelel a felhasználó alapértelmezett csoportjának, azaz a dev1 csoport a dev1 felhasználónak és a dev2 csoport a dev2 felhasználónak. (A fejlesztő alapcsoportjának megváltoztatása nem segít, mivel akkor hogyan dolgozzon több projekten?) Ebben az esetben a dev2 felhasználó nem tudja módosítani a dev1 által létrehozott fájlokat, ami funkcionalitási problémákat okozhat.

Linux chown — fájl tulajdonosának megváltoztatása normál felhasználók által

A fájl tulajdonosa nem tudja módosítani a tulajdonát. De megváltoztathatja a fájl csoportját, amelynek ő a tulajdonosa, így a fájl módosítása elérhetővé válhat más felhasználók számára, akik ugyanabba a csoportba tartoznak. 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 futtatható fájl, amelyet az a felhasználó hajt végre, aki a push-t végzi. Ezt tudva, végrehajthatjuk a megvalósítani kívántakat.

[dev1@server proj2]$ mv hooks/post-update{.sample,}
[dev1@server proj2]$ sed -i '2,$ s/^/#/' hooks/post-update
[dev1@server proj2]$ cat <<> hooks/post-update

vagy egyszerűen

vi hooks/post-update

Térjünk vissza az ügyfél gépére.

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:dev1@10.1.1.11's password:
   d22c66e..b045e22  master -> master

A Git szerveren ellenőrizzük a commit utáni hook post-update script működését

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

— üres, minden rendben van.

Második fejlesztő csatlakozása a Git-hez

Irányítjuk a második fejlesztő munkáját.

Az ügyfélnél

C:gittest>git remote remove origin

C:gittest>git remote add origin "ssh://dev2@10.1.1.11/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
dev2@10.1.1.11's password:
   b045e22..55d49a6  master -> master

És ugyanakkor, a szerveren...

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

— megint üres, minden működik.

Git projekt törlése és projekt letöltése a Git szerverről

Még egyszer ellenőrizhetjük, hogy minden változás megmaradt.

C:gittest>rd /S /Q .
A folyamat nem fér hozzá a fájlhoz, mivel ezt egy másik folyamat használja.

— a Git projekt eltávolításához egyszerűen teljesen töröljük a könyvtárat. El kell fogadnunk a hibát, mert a parancssal nem lehet törölni a jelenlegi könyvtárat, de pontosan ilyen viselkedésre van szükségünk.

C:gittest>dir
 A C:gittest könyvtár tartalma

21.06.2019  08:43              .
21.06.2019  08:43              ..

C:gittest>git clone ssh://dev2@10.1.1.11/var/gitservertest/proj2
Klónozás 'proj2'...\ndev2@10.1.1.11's password:

C:gittest>cd proj2

C:gittestproj2>dir
 A C:gittestproj2 könyvtár tartalma

21.06.2019  08:46              .
21.06.2019  08:46              ..
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 Git-ben

Most győződjünk meg róla, hogy a Git-en keresztül a második fejlesztő nem tud hozzáférni a Proj1 projekthez, amelyen nem dolgozik.

C:gittestproj2>git remote remove origin

C:gittestproj2>git remote add origin "ssh://dev2@10.1.1.11/var/gitservertest/proj1"

C:gittestproj2>git push origin master
dev2@10.1.1.11 jelszava:
fatal: '\var\gitservertest\proj1' nem tűnik git tárolónak
fatal: Nem lehetett olvasni a távoli tárolóból.

Kérjük, ellenőrizze, hogy megvannak-e a megfelelő hozzáférési jogai
és hogy a tároló létezik-e.

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

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

és ezután minden működik.

C:gittestproj2>git push origin master
dev2@10.1.1.11 jelszava:
To ssh://10.1.1.11/var/gitservertest/proj1
 * [új ágon]      master -> master

További információk

Továbbá, ha problémák merülnek fel a fájlok és könyvtárak alapértelmezett jogainál, CentOS alatt használhatja a parancsot

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

A cikkben apró hasznos dolgokkal is találkozhat:

hogyan építsünk könyvtárfát Linux alatt
hogyan adható meg a sed-ben címkék tartománya egy meghatározott sortól a fájl végéig, vagyis hogyan lehet a sed segítségével az összes sorban kicserélni a szöveget az első sor kivételével
Hogyan invertálható a keresési feltétel a find alatt Linuxon
hogyan lehet többsoros bemenetet átadni egy ciklusnak a shell alatt egy egyetlen sorban
hogyan kell escape-elni az egyes idézőjeleket bash-ben
hogyan lehet a parancssor alatt törölni egy könyvtárt minden tartalmával
Hogyan nevezhetünk át egy fájlt a bash mv paranccsal anélkül, hogy újra írnánk

Köszönöm a figyelmet.

Forrás: habr.com