Vairāku lietotāju piekļuves organizēšana GIT serverim

Instalējot un konfigurējot Git serveri, rodas jautājums par piekļuves organizēšanu vairākiem lietotājiem vairākiem projektiem. Es izpētīju problēmu un atradu risinājumu, kas atbilst visām manām prasībām: vienkāršs, drošs, uzticams.

Manas vēlmes ir:

• katrs lietotājs izveido savienojumu ar savu kontu
• Pie viena projekta var strādāt vairāki lietotāji
• viens un tas pats lietotājs var strādāt pie vairākiem projektiem
• katram lietotājam ir piekļuve tikai tiem projektiem, kuros viņš strādā
• Jābūt iespējai izveidot savienojumu, izmantojot komandrindu, nevis tikai caur kādu tīmekļa saskarni

Būtu arī lieliski:

• piešķirt kontrolējošām personām tikai lasīšanas atļaujas
• Ērti pārvaldiet lietotāja piekļuves tiesības pakalpojumā Git

Pārskats par iespējamām iespējām piekļūt GIT serverim

Pirmkārt, jums ir jāzina, no kā izvēlēties, tāpēc šeit ir īss Git protokolu pārskats.

• ssh - lai piekļūtu serverim, tiek izmantots speciāli izveidots lietotāja konts.
  • Dīvaini, ka Git no saviem ieteikumiem neizslēdz viena konta izmantošanu, lai piekļūtu visām krātuvēm. Tas nepavisam neatbilst manām prasībām.
  • Varat izmantot vairākus kontus, bet kā ierobežot lietotāju piekļuvi tikai noteiktiem direktorijiem?
    • Aizvēršanās mājas direktorijā nav piemērota, jo citiem lietotājiem tur ir grūti organizēt rakstīšanas piekļuvi
    • Sarežģīti ir arī izmantot simsaites no mājas direktorija, jo Git tās neinterpretē kā saites
    • Ir iespējams ierobežot piekļuvi tulkam, taču nav pilnīgas garantijas, ka tas vienmēr darbosies
      • Parasti šādiem lietotājiem varat pieslēgt savu komandu tulku, bet
        • pirmkārt, tas jau ir kaut kāds grūts lēmums,
        • un, otrkārt, to var apiet.

  Bet varbūt tā nav problēma, ka lietotājs varēs izpildīt kādas komandas?.. Kopumā šo metodi nevar izslēgt, ja izdomā, kā tieši to izmantot. Pie šīs metodes atgriezīsimies vēlāk, bet pagaidām īsi apsvērsim citas alternatīvas, iespējams, būs kas vienkāršāks.

• Vietējo protokolu git var izmantot kombinācijā ar sshfs, var izmantot vairākus lietotājus, bet būtībā tas pats, kas iepriekšējā gadījumā
• http — tikai lasāms
• git ir tikai lasāms
• https - grūti uzinstalēt, vajag papildus softu, kaut kādu vadības paneli, lai organizētu lietotāju pieeju... izskatās iespējams, bet kaut kā viss ir sarežģīti.

Ssh protokola izmantošana, lai organizētu vairāku lietotāju piekļuvi Git serverim

Atgriezīsimies pie ssh protokola.

Tā kā git izmantojat ssh piekļuvi, jums ir jānodrošina servera datu drošība. Lietotājs, kurš izveido savienojumu, izmantojot ssh, izmanto savu pieteikšanos Linux serverī, lai viņi varētu izveidot savienojumu, izmantojot ssh klientu, un piekļūt servera komandrindai.
Pilnīgas aizsardzības pret šādu piekļuvi nav.

Bet lietotājam nevajadzētu interesēties par Linux failiem. Nozīmīga informācija tiek glabāta tikai git repozitorijā. Tāpēc ir iespējams neierobežot piekļuvi caur komandrindu, bet izmantojot Linux rīkus, lai aizliegtu lietotājam skatīt projektus, izņemot tos, kuros viņš piedalās.
Acīmredzama izvēle ir izmantot Linux atļauju sistēmu.

Kā jau minēts, ssh piekļuvei ir iespējams izmantot tikai vienu kontu. Šī konfigurācija ir nedroša vairākiem lietotājiem, lai gan tā ir iekļauta ieteicamo git opciju sarakstā.

Lai īstenotu raksta sākumā norādītās prasības, tiek izveidota šāda direktoriju struktūra ar tiesību un īpašnieku piešķiršanu:

1) projektu katalogi

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
kur
dir1, dir2, dir3 - projektu katalogi: projekts 1, projekts 2, projekts 3.

proj1:proj1, proj2:proj2, proj3:proj3 ir īpaši izveidoti Linux lietotāji, kuri ir piešķirti kā attiecīgo projektu direktoriju īpašnieki.

atļaujas visiem direktorijiem ir iestatītas uz 0770 - pilnīga piekļuve īpašniekam un viņa grupai un pilnīgs aizliegums visiem pārējiem.

2) izstrādātāju konti

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

Galvenais ir tas, ka izstrādātājiem tiek piešķirta papildu attiecīgā projekta sistēmas lietotāja īpašnieku grupa. To veic Linux servera administrators ar vienu komandu.

Šajā piemērā "Izstrādātājs 1" strādā pie projektiem proj1 un proj2, un "Izstrādātājs 2" strādā pie projektiem proj2 un proj3.

Ja kāds no Izstrādātājiem izveido savienojumu, izmantojot ssh, izmantojot komandrindu, tad viņu tiesības nebūs pietiekamas pat to projektu direktoriju satura apskatei, kuros viņi nepiedalās. Viņš pats to nevar mainīt.

Tā kā šī principa pamatā ir Linux tiesību pamata drošība, šī shēma ir uzticama. Turklāt shēmu ir ļoti viegli administrēt.

Pāriet uz praksi.

Git repozitoriju izveide Linux serverī

Pārbaudīsim.

[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

Man ir apnicis rakstīt ar roku...

[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

Mēs esam pārliecināti, ka no komandrindas nav iespējams piekļūt citu cilvēku krātuvēm un pat apskatīt to saturu.

[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

Sadarbojieties ar vairākiem izstrādātājiem vienā Git projektā

Paliek viens jautājums, ja viens izstrādātājs ievieš jaunu failu, tad citi izstrādātāji to nevar mainīt, jo viņš pats ir tā īpašnieks (piemēram, dev1), nevis projekta lietotājs (piemēram, proj1). Tā kā mums ir servera puses repozitorijs, vispirms mums ir jāzina, kā ir strukturēts “.git” direktorijs un vai tiek izveidoti jauni faili.

Vietējās Git repozitorija izveide un nosūtīšana uz Git serveri

Pāriesim pie klienta mašīnas.

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>

Tajā pašā laikā serverī tiek izveidoti jauni faili, un tie pieder lietotājam, kurš veica 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]$

Augšupielādējot izmaiņas Git serverī, tiek izveidoti papildu faili un direktoriji, un to īpašnieks faktiski ir lietotājs, kurš veic augšupielādi. Bet tad šo failu un direktoriju grupa atbilst arī šī lietotāja galvenajai grupai, tas ir, dev1 grupai dev1 lietotājam un dev2 grupai dev2 lietotājam (izstrādātāja lietotāja galvenās grupas maiņa nepalīdzēs, jo kā tad jūs varat strādāt pie vairākiem projektiem?). Šādā gadījumā lietotājs dev2 nevarēs mainīt lietotāja dev1 izveidotos failus, kas var izraisīt funkcionalitātes traucējumus.

Linux chown - parasts lietotājs maina faila īpašnieku

Faila īpašnieks nevar mainīt tā īpašumtiesības. Bet viņš var mainīt viņam piederošā faila grupu, un tad šo failu var modificēt citi lietotāji, kas ir tajā pašā grupā. Tas ir tas, kas mums vajadzīgs.

Izmantojot Git āķi

Āķa darba direktorijs ir projekta saknes direktorijs. hook ir izpildāmā fails, kas darbojas zem lietotāja, kas veic push. Zinot to, mēs varam īstenot savus plānus.

[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

vai vienkārši

vi hooks/post-update

Atgriezīsimies pie klienta mašīnas.

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

Git serverī mēs pārbaudām āķa pēcatjaunināšanas skripta darbību pēc commit

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

- tukšs, viss kārtībā.

Otra izstrādātāja savienošana pakalpojumā Git

Simulēsim otrā izstrādātāja darbu.

Uz klientu

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

Un tajā pašā laikā serverī...

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

— atkal tukšs, viss strādā.

Git projekta dzēšana un projekta lejupielāde no Git servera

Nu, jūs varat vēlreiz pārliecināties, ka visas izmaiņas ir saglabātas.

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

— lai izdzēstu Git projektu, vienkārši pilnībā notīriet direktoriju. Samierināsimies ar ģenerēto kļūdu, jo, izmantojot šo komandu, pašreizējo direktoriju nav iespējams dzēst, taču tieši tā mums ir nepieciešama.

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"

Piekļuves koplietošana pakalpojumā Git

Tagad pārliecināsimies, ka pat caur Git otrais izstrādātājs nevar piekļūt Proj1 projektam, ar kuru viņš nestrādā.

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.

Tagad mēs atļaujam piekļuvi

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

un pēc tam viss darbojas.

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

Lai iegūtu vairāk informācijas,

Turklāt, ja, veidojot failus un direktorijus, rodas problēma ar noklusējuma atļaujām, CentOS varat izmantot komandu

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

Arī rakstā jūs varat paklupt uz mazām noderīgām lietām:

• kā izveidot direktoriju koku operētājsistēmā Linux
• kā nodot sed adrešu diapazonu no noteiktas rindiņas līdz faila beigām, tas ir, veikt sed nomaiņu visās rindās, izņemot pirmo rindiņu
• Kā apgriezt meklēšanas nosacījumu Linux atrašanā
• Kā ievadīt vairākas rindiņas cilpā, izmantojot vienu līnijpārvadātāju Linux apvalkā
• Kā izvairīties no vienpēdiņiem bash
• kā izdzēst direktoriju ar visu tā saturu Windows komandrindā
• Kā izmantot bash mv, lai pārdēvētu failu, nepārrakstot to vēlreiz

Paldies par uzmanību.

Avots: www.habr.com