🥇Mitme kasutaja ligipääsu korraldamine GIT serveris

Git-serveri paigaldamisel ja konfigureerimisel tekib küsimus, kuidas organiseerida juurdepääs mitme kasutaja poolt mitmele projektile. Olen uurinud seda küsimust ja leidnud lahenduse, mis vastab kõikidele minu nõudmistele: lihtne, turvaline, usaldusväärne.

Minu soovid on järgmised:

iga kasutaja logib sisse oma isikliku kontoga
ühe projekti kallal võivad töötada mitu kasutajat
sama kasutaja võib töötada mitme projekti kallal
iga kasutaja pääseb ligi ainult neile projektidele, milles ta osaleb
peab olema võimalik sisse logida ka käsurealt, mitte ainult mingi veebiliidese kaudu

Oleks ka tore:

anda lugemisõigused ainult järelevalveisikutele
mugavalt hallata kasutajate juurdepääsuõigusi Git-is

Ülevaade võimalikest juurdepääsuvariantidest Git-serveris

Esiteks, tuleb teada, millest valida, seetõttu on lühike ülevaade Git-protokollidest.

ssh - serverisse pääsemiseks kasutatakse spetsiaalselt loodud kasutajakontot.
- Imelik, et Git ei soovita kasutada ühte kontot kõigile repodele. See ei vasta minu nõudmistele.
- Võib kasutada mitut kontot, kuid kuidas piirata kasutaja juurdepääs ainult teatud kataloogidele?
  - Kodu katalooge lukustamine ei sobi, kuna on keeruline korraldada sinna kirjutamisõigust teistele kasutajatele.
  - Sümboolsete linkide kasutamine kodukataloogidest on samuti keeruline, kuna Git ei tõlgenda neid linkidena.
  - Juurdepääsu piiramine tõlgendajale on võimalik, kuigi ei ole täielikku garantiid, et see alati töötab.
    - Saab pingutada selleks, et anda neile kasutajatele oma käsurea tõlgendaja, kuid
      - esiteks, see on kuidagi keeruline lahendus,
      - teiseks, seda on võimalik ümber käia.
Aga võib-olla ei tohiks probleemiks pidada, et kasutaja saab käivitada kõiki käske?.. Ühesõnaga, seda meetodit ei tohi välistada, kui välja mõelda, kuidas seda kasutada. Tuleme selle meetodi juurde hiljem tagasi, aga hetkel vaatame lühidalt üle teised alternatiivid, võib-olla seal on midagi lihtsamat.
Git'i kohalik protokoll saab kasutada koos sshfs-iga, mitme kasutaja kasutamine on võimalik, kuid sisuliselt on see sama, mis eelmine juhtum.
HTTP — ainult lugemiseks.
Git — ainult lugemiseks.
HTTPS — keeruline seadistada, vajab täiendavat tarkvara, mingisugust. juhtpaneel Kasutajate juurdepääsu korraldamine… näeb välja teostatav, kuid kõik on kuidagi keeruline.

SSH protokolli kasutamine mitme kasutaja juurdepääsu korraldamiseks Git-serverisse.

Naaseme SSH protokooli juurde.

Kuna Git kasutab SSH-ühendust, tuleb tagada serveri andmete turvalisus. Kasutaja, kes ühendub SSH kaudu, kasutab oma sisselogimist Linuxis. serveris Seetõttu saab ta ühenduda SSH-kliendiga ja pääseda juurde serveri käsureale.
Täielikku kaitset sellise juurdepääsu eest ei ole.

Kuid kasutajale ei tohiks huvi pakkuda Linuxi failid. Oluline teave hoitakse ainult Git repositooriumis. Seetõttu ei peaks juurdepääsu käsureale piirama, vaid tuleb Linuxi vahenditega keelata kasutajal projektide vaatamine, välja arvatud need, milles ta osaleb.
On ilmne, et on mõistlik kasutada Linuxi juurdepääsuõiguste süsteemi.

Nagu juba mainitud, on võimalik kasutada ainult ühte kontot SSH-juurdepääsuks. Selline konfiguratsioon on mitme kasutaja jaoks ebaturvaline, kuigi see meetod on soovitatavate Git-variantide nimekirjas.

Eespool artiklis esitatud nõuete rakendamiseks luuakse järgmine kaustade struktuur koos õiguste ja omanike määramisega:

1) projektikaustad

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
…
kus
dir1, dir2, dir3 — projektikaustad: projekt 1, projekt 2, projekt 3.

proj1:proj1, proj2:proj2, proj3:proj3 — spetsiaalselt loodud Linuxi kasutajad, kes määratakse vastavate projektikaustade omanikeks.

Kõikide kaustade õigused on määratud 0770 — täielik juurdepääs omanikule ja tema grupile ning täielik keeld kõigile teistele.

2) arendajate kontod

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

Oluline punkt on see, et arendajatele määratakse vastava projekti süsteemi kasutaja omanikule lisagrupp. Seda teeb Linuxi serveri administraator ühe käsuga.

Selles näites töötab «Arendaja 1» projekti proj1 ja proj2 kallal, samas kui «Arendaja 2» töötab projektide proj2 ja proj3 kallal.

Kui ükskõik milline Arendajatest ühendab SSH kaudu käsurea kaudu, ei piisa tema õigustest isegi projektide sisu vaatamisest, milles ta ei osale. Ta ei saa seda ise muuta.

Kuna selle põhimõtte aluseks on Linuxi õiguste põhiline turvalisus, on see skeem usaldusväärne. Lisaks on skeemi administreerimine väga lihtne.

Liigume praktika juurde.

Git'i hoidlate loomine Linuxi serveris

Kontrollime.

[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

on tüütav käsitsi sisestada...

[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

Veendume, et käsurea kaudu ei saa juurdepääsu teiste hoidlatele ega isegi nende sisu vaadata.

[dev1@server ~]$ cd /var/gitservertest/proj3
-bash: cd: /var/gitservertest/proj3: Juurdepääs keelatud
[dev1@server ~]$ ls /var/gitservertest/proj3
ls: ei saa avada katalooge /var/gitservertest/proj3: Juurdepääs keelatud

Mitme arendaja koostöö Git'is ühe projekti kallal

Küsimus jääb, kui üks arendaja lisab uue faili, ei saa teised arendajad seda muuta, kuna tema on selle omanik (näiteks dev1), mitte projekti omanik (näiteks proj1). Kuna meil on serveripõhine hoidla, tuleb kõigepealt teada, kuidas on korraldatud kataloog «.git» ja kas uued failid luuakse.

Kohaliku Git hoidla loomine ja pushimine Git serverisse

Liigume kliendimasinale.

Microsoft Windows [Version 6.1.7601]
(c) Microsoft Corporation, 2009. Все права защищены.

C:gittest>git init .
Инициализирован пустой репозиторий Git в C:/gittest/.git/

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

C:gittest>git add .

C:gittest>git status
На ветке master
Еще нет коммитов
Изменения будут добавлены:
  (используйте "git rm --cached <file>..." чтобы удалить из staging)
		новый файл:   test1.txt

C:gittest>git commit -am "новый тестовый файл добавлен"
[master (root-commit) a7ac614] новый тестовый файл добавлен
 1 файл изменен, 1 вставка(+)
 создан режим 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's пароль:
Подсчет объектов: 3, сделано.
Запись объектов: 100% (3/3), 243 байта | 243.00 KiB/с, сделано.
Всего 3 (delta 0), использовано 0 (delta 0)
В ssh://10.1.1.11/var/gitservertest/proj2
 * [новая ветка]      master -> master

C:gittest>

В это же время на сервере образуются новые файлы, которые принадлежат пользователю, который выполнил 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 директорий, 18 файлов
[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]$

При загрузке изменений на сервер Git создаются дополнительные файлы и директории, причем их владельцем действительно является тот пользователь, который делает загрузку. Но тогда и группа этих файлов и директорий также соответствует основной группе этого пользователя, то есть, группа dev1 для пользователя dev1 и группа dev2 для пользователя dev2. Смена основной группы пользователя-разработчика не поможет, поскольку тогда как работать над несколькими проектами? В таком случае, пользователь dev2 не сможет изменять файлы, созданные пользователем dev1, что может привести к функциональным проблемам.

Linux chown — изменение владельца файла обычным пользователем

Владелец файла не может изменять его принадлежность. Но он может изменить группу файла, который ему принадлежит, и тогда этот файл может быть доступен для изменения другим пользователям, находящимся в этой же группе. Это именно то, что нам нужно.

Использование Git hook

Hook'i töökaust on projekti juurkataloog. Hook on täitmisfail, mis käivitatakse kasutaja all, kes teeb push'i. Seda teades saame teostada kavandatut.

[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

või lihtsalt

vi hooks/post-update

Naaseme kliendimasinale.

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

Kontrollime Git serveris hook'i post-update skripti tööd pärast commiti.

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

— tühi, kõik on korras.

Teise arendaja ühendamine Git'is

Simuleerime teise arendaja tööd.

Kliendis

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

Ja samal ajal, serveris...

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

— jälle tühi, kõik töötab.

Git projekti eemaldamine ja projekti allalaadimine Git serverist

Katsume veel kord veenduda, et kõik muudatused on salvestatud.

C:gittest>rd /S /Q .
Protsess ei saa faili juurde pääseda, kuna see on teise protsessi poolt hõivatud.

— Git projekti eemaldamiseks puhastame lihtsalt katalooge täielikult. Leppime välja antava veaga, kuna ei ole võimalik eemaldada praegust katalooge selle käsu järgi, kuid me vajame just sellist käitumist.

C:gittest>dir
 Katalooge sisu C:gittest

21.06.2019  08:43              .
21.06.2019  08:43              ..

C:gittest>git clone ssh://dev2@10.1.1.11/var/gitservertest/proj2
Kloonimine 'proj2'...
dev2@10.1.1.11's password:

C:gittest>cd proj2

C:gittestproj2>dir
 Katalooge sisu C:gittestproj2

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"

Ligipääsu jagamine Git'is

Veendume nüüd, et teise arendaja kaudu Git'iga ei saa ta Proj1 projekti juurde pääseda, millega ta ei tööta.

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 parool:
fatal: '/var/gitservertest/proj1' ei tundu olevat git hoidla
fatal: Ei saanud kaughoidlast lugeda.

Palun veenduge, et teil on õiged ligipääsuõigused
ja hoidla eksisteerib.

Nüüd lubame ligipääsu

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

ja pärast seda kõik töötab.

C:gittestproj2>git push origin master
dev2@10.1.1.11 parool:
Kohale ssh://10.1.1.11/var/gitservertest/proj1
 * [uus haru]      master -> master

Täiendavad andmed

Lisaks, kui uute failide ja kataloogide loomisega on vaikimisi probleeme õigustega, saab CentOSis kasutada käsku

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

Samuti võite artiklis kohata väikeseid kasulikke asju:

kuidas luua kataloogipuud Linuxis
kuidas edastada aadresside vahemikku sedis teatud reast faili lõpuni, st asendada sedis kõikides ridades, välja arvatud esimeses reas
Kuidas leida Linuxis tingimust otsingu pööramiseks
kuidas luua Linuxi shellis tsüklis mitme rea edastamine ühe reaga
kuidas bashis üksi jutumärke ära märkida
kuidas Windowsi käsurealt kustutada katalooge koos kogu sisuga
Kuidas kasutada bash mv, et fail ümber nimetada, kirjutamata seda uuesti üle

Aitäh tähelepanu eest.

Allikas: habr.com