ProHoster > Dienoraštis > Administravimas > Kelių vartotojų prieigos prie GIT serverio organizavimas

Kelių vartotojų prieigos prie GIT serverio organizavimas

Diegiant ir konfigūruojant Git serverį kyla klausimas, kaip organizuoti kelių vartotojų prieigą prie kelių projektų. Ištyriau problemą ir radau sprendimą, atitinkantį visus mano reikalavimus: paprastas, saugus, patikimas.

Mano pageidavimai yra:

  • kiekvienas vartotojas prisijungia prie savo paskyros
  • Prie vieno projekto gali dirbti keli vartotojai
  • tas pats vartotojas gali dirbti su keliais projektais
  • kiekvienas vartotojas turi prieigą tik prie tų projektų, kuriuose dirba
  • Turėtų būti įmanoma prisijungti per komandinę eilutę, o ne tik per kokią nors žiniatinklio sąsają

Taip pat būtų puiku:

  • suteikti tik skaitymo teises kontroliuojantiems asmenims
  • Patogiai valdykite vartotojo prieigos teises „Git“.

Galimų prieigos prie GIT serverio parinkčių apžvalga

Visų pirma, jūs turite žinoti, ką pasirinkti, todėl čia yra trumpa Git protokolų apžvalga.

  • ssh – prieigai prie serverio naudojama specialiai sukurta vartotojo abonementas.
    • Keista, kad „Git“ iš savo rekomendacijų neatmeta galimybės naudoti vieną paskyrą norint pasiekti visas saugyklas. Tai visiškai neatitinka mano reikalavimų.
    • Galite naudoti kelias paskyras, bet kaip galite apriboti vartotojo prieigą tik prie tam tikrų katalogų?
      • Uždaryti namų katalogą netinka, nes sunku jame organizuoti rašymo prieigą kitiems vartotojams
      • Naudoti simbolių nuorodas iš namų katalogo taip pat sunku, nes „Git“ jų neinterpretuoja kaip nuorodų
      • Galima apriboti prieigą prie vertėjo, tačiau nėra visiškos garantijos, kad jis veiks visada
        • Paprastai tokiems vartotojams galite prijungti savo komandų interpretatorių, bet
          • pirma, tai jau kažkoks sunkus sprendimas,
          • ir, antra, tai galima apeiti.

    Bet gal ne bėda, kad vartotojas galės vykdyti kokias nors komandas?.. Apskritai šio būdo negalima atmesti, jei tiksliai išsiaiškinsi kaip juo naudotis. Prie šio metodo grįšime vėliau, bet kol kas trumpai apsvarstysime kitas alternatyvas, gal bus kažkas paprastesnio.

  • Git vietinis protokolas gali būti naudojamas kartu su sshfs, gali būti naudojami keli vartotojai, bet iš esmės tas pats kaip ir ankstesnis atvejis
  • http – tik skaitomas
  • git yra tik skaitomas
  • https - sunku įdiegti, reikia papildomos programinės įrangos, kažkokio valdymo pulto, kad būtų galima organizuoti vartotojo prieigą... atrodo įmanoma, bet kažkaip viskas sudėtinga.

Ssh protokolo naudojimas norint organizuoti kelių vartotojų prieigą prie Git serverio

Grįžkime prie ssh protokolo.

Kadangi git naudojate ssh prieigą, turite užtikrinti serverio duomenų saugumą. Vartotojas, kuris prisijungia per ssh, naudoja savo prisijungimą prie Linux serverio, todėl gali prisijungti per ssh klientą ir pasiekti serverio komandų eilutę.
Visiškos apsaugos nuo tokios prieigos nėra.

Tačiau vartotojas neturėtų domėtis Linux failais. Svarbi informacija saugoma tik git saugykloje. Todėl galima apriboti prieigą ne per komandinę eilutę, o naudojant Linux įrankius, kad būtų uždrausta vartotojui žiūrėti projektus, išskyrus tuos, kuriuose jis dalyvauja.
Akivaizdus pasirinkimas yra naudoti „Linux“ leidimų sistemą.

Kaip jau minėta, ssh prieigai galima naudoti tik vieną paskyrą. Ši konfigūracija yra nesaugi keliems vartotojams, nors ji įtraukta į rekomenduojamų git parinkčių sąrašą.

Straipsnio pradžioje pateiktiems reikalavimams įgyvendinti sukuriama tokia katalogų struktūra, priskiriant teises ir savininkus:

1) projektų katalogai

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
kur
dir1, dir2, dir3 - projektų katalogai: projektas 1, projektas 2, projektas 3.

proj1:proj1, proj2:proj2, proj3:proj3 yra specialiai sukurti Linux vartotojai, kurie priskirti atitinkamų projektų katalogų savininkams.

visų katalogų leidimai nustatyti į 0770 – visa prieiga savininkui ir jo grupei ir visiškas draudimas visiems kitiems.

2) kūrėjų paskyros

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

Svarbiausia yra tai, kad kūrėjams yra priskiriama papildoma atitinkamo projekto sistemos naudotojo savininko grupė. Tai atlieka Linux serverio administratorius viena komanda.

Šiame pavyzdyje „Kūrėjas 1“ dirba su projektais proj1 ir proj2, o „Developer 2“ – su projektais proj2 ir proj3.

Jei kuris nors iš Kūrėjų prisijungia per ssh per komandinę eilutę, tada jų teisių nepakaks net norint peržiūrėti projektų katalogų, kuriuose jie nedalyvauja, turinį. Jis pats negali to pakeisti.

Kadangi šio principo pagrindas yra pagrindinis Linux teisių saugumas, ši schema yra patikima. Be to, schemą labai lengva administruoti.

Pereikime į praktiką.

„Git“ saugyklų kūrimas „Linux“ serveryje

Mes tikriname.

[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

Pavargau rašyti ranka...

[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

Esame įsitikinę, kad iš komandinės eilutės neįmanoma pasiekti kitų žmonių saugyklų ir net peržiūrėti jų turinio.

[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

Bendradarbiaukite su keliais kūrėjais vykdydami tą patį projektą „Git“.

Lieka vienas klausimas, jei vienas kūrėjas įveda naują failą, tai kiti kūrėjai negali jo pakeisti, nes jis pats yra jo savininkas (pvz., dev1), o ne projekto savininkas vartotojas (pvz., proj1). Kadangi turime serverio saugyklą, pirmiausia turime žinoti, kaip struktūrizuotas „.git“ katalogas ir ar kuriami nauji failai.

Vietinės Git saugyklos sukūrimas ir siuntimas į Git serverį

Pereikime prie kliento mašinos.

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>

Tuo pačiu metu serveryje sukuriami nauji failai, kurie priklauso vartotojui, kuris atliko siuntimą

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

Kai įkeliate pakeitimus į „Git“ serverį, sukuriami papildomi failai ir katalogai, o jų savininkas iš tikrųjų yra įkėlimą atliekantis vartotojas. Bet tada šių failų ir katalogų grupė taip pat atitinka pagrindinę šio vartotojo grupę, ty dev1 grupę dev1 vartotojui ir dev2 grupę dev2 vartotojui (pagrindinės kūrėjo vartotojo grupės keitimas nepadės, nes kaip tada galima dirbti su keliais projektais?). Tokiu atveju vartotojas dev2 negalės pakeisti dev1 vartotojo sukurtų failų, todėl gali sugesti funkcionalumas.

„Linux chown“ – failo savininko pakeitimas, kurį atlieka paprastas vartotojas

Failo savininkas negali pakeisti jo nuosavybės. Bet jis gali pakeisti jam priklausančio failo grupę, o tada šį failą gali keisti kiti toje pačioje grupėje esantys vartotojai. Štai ko mums reikia.

Naudojant Git Hook

Kabliuko darbo katalogas yra projekto šakninis katalogas. hook yra vykdomasis failas, kuris paleidžiamas vartotojui, atliekančiam paspaudimą. Tai žinodami galime įgyvendinti savo planus.

[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

arba tiesiog 

vi hooks/post-update

Grįžkime prie kliento mašinos.

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“ serveryje tikriname „hook“ po atnaujinimo scenarijaus veikimą po įvykdymo 

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

- Tuščia, viskas gerai.

Antrojo kūrėjo prijungimas sistemoje „Git“.

Modeliuokime antrojo kūrėjo darbą.

Ant kliento

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

Ir tuo pačiu serveryje...

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

— vėl tuščia, viskas veikia.

„Git“ projekto ištrynimas ir projekto atsisiuntimas iš „Git“ serverio

Na, galite dar kartą įsitikinti, kad visi pakeitimai buvo išsaugoti.

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

- Norėdami ištrinti Git projektą, tiesiog visiškai išvalykite katalogą. Susitaikykime su sugeneruota klaida, nes naudojant šią komandą neįmanoma ištrinti dabartinio katalogo, tačiau mums reikia būtent tokio elgesio.

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"

Prieigos bendrinimas naudojant „Git“.

Dabar įsitikinkime, kad net per „Git“ antrasis kūrėjas negali pasiekti „Proj1“ projekto, kuriame jis nedirba.

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.

Dabar suteikiame prieigą

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

ir po to viskas veikia.

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

Norėdami gauti daugiau informacijos,

Be to, jei kuriant failus ir katalogus kyla problemų dėl numatytųjų leidimų, CentOS galite naudoti komandą

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

Taip pat straipsnyje galite sutikti mažų naudingų dalykų:

  • kaip sukurti katalogų medį Linux
  • kaip perduoti adresų diapazoną sed nuo tam tikros eilutės iki failo pabaigos, tai yra pakeisti sed visose eilutėse, išskyrus pirmąją eilutę
  • Kaip pakeisti paieškos sąlygą „Linux find“.
  • Kaip perkelti kelias eilutes į kilpą naudojant vieną liniją Linux apvalkale
  • Kaip išvengti pavienių kabučių bash
  • kaip ištrinti katalogą su visu jo turiniu Windows komandinėje eilutėje
  • Kaip naudoti bash mv pervardyti failą neperrašant jo dar kartą

Ačiu už dėmesį.

Šaltinis: www.habr.com

Добавить комментарий