ProHoster > Blog > administrasie > Organisasie van multi-gebruiker toegang tot die GIT bediener

Organisasie van multi-gebruiker toegang tot die GIT bediener

Wanneer 'n Git-bediener geïnstalleer en gekonfigureer word, ontstaan ​​​​die vraag om toegang vir verskeie gebruikers tot verskeie projekte te organiseer. Ek het 'n bietjie navorsing oor die kwessie gedoen en 'n oplossing gevind wat aan al my vereistes voldoen: eenvoudig, veilig, betroubaar.

My wense is:

  • elke gebruiker verbind met hul eie rekening
  • Veelvuldige gebruikers kan aan dieselfde projek werk
  • dieselfde gebruiker kan aan verskeie projekte werk
  • elke gebruiker het slegs toegang tot daardie projekte waaraan hy werk
  • dit moet moontlik wees om deur die opdragreël te koppel, en nie net deur 'n soort webkoppelvlak nie

Dit sal ook wonderlik wees:

  • leesalleenregte aan beherende persone toestaan
  • administreer gebruikerstoestemmings gerieflik in Git

Oorsig van moontlike opsies vir toegang tot die GIT-bediener

Eerstens moet u weet waaruit u moet kies, dus 'n kort oorsig van die Git-protokolle.

  • ssh - 'n spesiaal geskepte gebruikersrekening word gebruik om toegang tot die bediener te kry.
    • dit is vreemd dat Git nie aanbeveel om een ​​rekening te gebruik om toegang tot alle bewaarplekke te verkry nie. Dit voldoen glad nie aan my vereistes nie.
    • Jy kan veelvuldige rekeninge gebruik, maar hoe kan jy 'n gebruiker se toegang tot slegs sekere dopgehou beperk?
      • Die sluiting van die tuisgids is nie geskik nie, want dit is moeilik om skryftoegang vir ander gebruikers daar te organiseer
      • Die gebruik van simboliese skakels vanaf die tuisgids is ook moeilik omdat Git dit nie as skakels interpreteer nie.
      • Beperk toegang tot die tolk, wel, jy kan, maar daar is geen volle waarborg dat dit altyd sal werk nie
        • U kan gewoonlik u eie opdragtolk vir sulke gebruikers koppel, maar,
          • eerstens, dit is reeds 'n soort moeilike besluit,
          • en 2, dit kan omseil word.

    Maar miskien is dit nie 'n probleem dat die gebruiker enige opdragte sal kan uitvoer nie? .. Oor die algemeen kan hierdie metode nie uitgesluit word as jy uitvind hoe om dit te gebruik nie. Ons sal later na hierdie metode terugkeer, maar vir nou sal ons die oorblywende alternatiewe kortliks oorweeg, miskien sal daar iets eenvoudiger wees.

  • git plaaslike protokol kan in kombinasie met sshfs gebruik word, verskeie gebruikers kan gebruik word, maar dit is in wese dieselfde as die vorige geval
  • http - slegs lees
  • git is leesalleen
  • https is moeilik om te installeer, jy benodig bykomende sagteware, 'n soort beheerpaneel om gebruikerstoegang te organiseer ... dit lyk haalbaar, maar op een of ander manier is alles ingewikkeld.

Gebruik die ssh-protokol om multi-gebruiker toegang tot die Git-bediener te organiseer

Kom ons keer terug na die ssh-protokol.

Aangesien ssh-toegang vir git gebruik word, moet die bedienerdata veilig wees. Die gebruiker wat via ssh koppel, gebruik hul eie aanmelding op die Linux-bediener, sodat hulle via die ssh-kliënt kan koppel en toegang tot die bediener se opdragreël kan kry.
Daar is geen volledige beskerming teen die verkryging van sulke toegang nie.

Maar die gebruiker behoort nie in Linux-lêers belang te stel nie. Betekenisvolle inligting word slegs in die git-bewaarplek gestoor. Daarom kan u nie toegang deur die opdragreël beperk nie, maar deur middel van Linux die gebruiker verbied om projekte te bekyk, behalwe dié waaraan hy deelneem.
Dit is voor die hand liggend om die Linux-toestemmingstelsel te gebruik.

Soos reeds genoem, is dit moontlik om slegs een rekening vir ssh-toegang te gebruik. Hierdie konfigurasie is onveilig vir verskeie gebruikers, hoewel dit ingesluit is in git se lys van aanbevole opsies.

Om die vereistes wat aan die begin van die artikel gegee word, te implementeer, word die volgende gidsstruktuur geskep met die toewysing van regte en eienaars:

1) projekgidse

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
waar
dir1, dir2, dir3 - projekgidse: projek 1, projek 2, projek 3.

proj1:proj1, proj2:proj2, proj3:proj3 is spesiaal geskepde Linux-gebruikers wat as die eienaars van die onderskeie projekgidse aangewys is.

die regte op alle gidse is ingestel op 0770 - volle toegang vir die eienaar en sy groep, en 'n algehele verbod vir almal anders.

2) ontwikkelaarrekeninge

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

Die sleutelpunt is dat die ontwikkelaars 'n bykomende groep van die stelselgebruiker wat die ooreenstemmende projek besit, toegewys word. Dit word gedoen deur die Linux-bedieneradministrateur met een opdrag.

In hierdie voorbeeld werk ontwikkelaar 1 aan projekte proj1 en proj2, en ontwikkelaar 2 werk aan projekte proj2 en proj3.

As enige van die ontwikkelaars via ssh via die opdragreël verbind, sal sy regte nie eers genoeg wees om die inhoud van die gidse van projekte waaraan hy nie deelneem nie, te sien. Hy kan dit nie self verander nie.

Aangesien die basis van hierdie beginsel die basiese sekuriteit van Linux-regte is, is hierdie skema betroubaar. Boonop is die skema baie maklik om te administreer.

Kom ons gaan oor na oefening.

Skep Git-bewaarplekke op 'n Linux-bediener

Ons kontroleer.

[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

moeg getik...

[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

Ons is oortuig daarvan dat dit onmoontlik is om toegang tot ander mense se bewaarplekke vanaf die opdragreël te verkry en selfs die inhoud daarvan te bekyk.

[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

Samewerking in Git van verskeie ontwikkelaars op een projek

Een vraag bly, as een ontwikkelaar 'n nuwe lêer bekendstel, kan ander ontwikkelaars dit nie verander nie, want hy is self die eienaar daarvan (byvoorbeeld dev1), en nie die gebruiker wat die projek besit nie (byvoorbeeld proj1). Aangesien ons 'n bedienerbewaarplek het, moet ons eerstens weet hoe die ".git"-gids gerangskik is en of nuwe lêers geskep word.

Skep 'n plaaslike Git-bewaarplek en druk na 'n Git-bediener

Kom ons gaan aan na die kliëntmasjien.

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>

Terselfdertyd word nuwe lêers op die bediener gegenereer, en dit behoort aan die gebruiker wat die druk uitgevoer het

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

Wanneer die veranderinge na die Git-bediener opgelaai word, word bykomende lêers en gidse geskep en word dit eintlik deur die oplaaier besit. Maar dan stem die groep van hierdie lêers en gidse ook ooreen met die hoofgroep van hierdie gebruiker, dit wil sê die dev1-groep vir die dev1-gebruiker en die dev2-groep vir die dev2-gebruiker (om die ontwikkelaargebruiker se hoofgroep te verander, sal nie help nie, want dan hoe om aan verskeie projekte te werk?). In hierdie geval sal die dev2-gebruiker nie die lêers wat deur die dev1-gebruiker geskep is, kan verander nie, en dit is belaai met 'n skending van funksionaliteit.

Linux chown - verander die eienaar van 'n lêer deur 'n normale gebruiker

Die eienaar van 'n lêer kan nie sy eienaarskap verander nie. Maar hy kan die groep verander van 'n lêer wat aan hom behoort, en dan kan hierdie lêer verander word deur ander gebruikers wat in dieselfde groep is. Dit is wat ons nodig het.

Gebruik die Git Hook

Die werkgids vir haak is die wortelgids van die projek. hook is 'n uitvoerbare lêer wat onder die gebruiker loop wat die druk doen. as ons dit weet, kan ons ons planne uitvoer.

[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

óf net 

vi hooks/post-update

Kom ons gaan terug na die kliëntmasjien.

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

Kontroleer op die Git-bediener die werk van die haak-na-opdateringskrip na die commit 

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

- leeg, alles is reg.

Koppel 'n tweede ontwikkelaar aan Git

Kom ons simuleer die werk van die tweede ontwikkelaar.

Op die kliënt

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

En terselfdertyd, op die bediener ...

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

- weer leeg, alles werk.

Vee 'n Git-projek uit en laai 'n projek vanaf 'n Git-bediener

Wel, jy kan weer seker maak dat al die veranderinge gestoor is.

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

- Om 'n Git-projek te verwyder, maak eenvoudig die gids heeltemal skoon. Kom ons verdra die fout wat gegee word, aangesien dit onmoontlik is om die huidige gids met hierdie opdrag uit te vee, maar dit is presies die gedrag wat ons nodig het.

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"

Deel toegang in Git

Kom ons maak nou seker dat die tweede ontwikkelaar nie toegang tot die Proj1-projek deur Git kan kry nie, waaraan hy nie werk nie.

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.

Laat nou toegang toe

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

en daarna werk alles.

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

Vir meer inligting,

Daarbenewens, as daar 'n probleem is met die verstektoestemmings wanneer u lêers en gidse skep, kan u op CentOS die opdrag gebruik

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

Ook in die artikel kan jy op klein nuttige dinge struikel:

  • hoe om 'n gidsboom in Linux te bou
  • hoe om 'n reeks adresse van 'n sekere reël na die einde van die lêer in sed deur te gee, dit wil sê om 'n vervanging in sed in alle reëls behalwe die eerste reël te maak
  • Hoe om soektoestand in Linux vind om te keer
  • hoe om veelvuldige lyne deur 'n eenvoering in 'n linux-dop te stuur
  • hoe om enkele aanhalings in bash te ontsnap
  • hoe om 'n gids met alle inhoud in die Windows-opdragreël uit te vee
  • Hoe om 'n lêer te hernoem met bash mv sonder om dit te herskryf

Dankie vir jou aandag.

Bron: will.com

Voeg 'n opmerking