ProHoster > Blog > uprava > Organizacija višekorisničkog pristupa GIT poslužitelju

Organizacija višekorisničkog pristupa GIT poslužitelju

Prilikom instaliranja i konfiguriranja Git poslužitelja postavlja se pitanje organiziranja pristupa za nekoliko korisnika na nekoliko projekata. Istražio sam problem i pronašao rješenje koje je zadovoljilo sve moje zahtjeve: jednostavno, sigurno, pouzdano.

Moje želje su:

  • svaki se korisnik povezuje sa svojim računom
  • Na jednom projektu može raditi više korisnika
  • isti korisnik može raditi na više projekata
  • svaki korisnik ima pristup samo onim projektima na kojima radi
  • Trebalo bi se moći povezati preko naredbenog retka, a ne samo preko nekakvog web sučelja

Također bi bilo super:

  • dodijeliti dozvole samo za čitanje osobama koje kontroliraju
  • Lako upravljajte korisničkim pravima pristupa u Gitu

Pregled mogućih mogućnosti pristupa GIT poslužitelju

Prije svega, morate znati što odabrati, pa evo kratkog pregleda Git protokola.

  • ssh - za pristup poslužitelju koristi se posebno kreiran korisnički račun.
    • Čudno je da Git ne isključuje iz svojih preporuka korištenje jednog računa za pristup svim spremištima. Ovo uopće ne ispunjava moje zahtjeve.
    • Možete koristiti više računa, ali kako možete ograničiti korisnički pristup samo na određene direktorije?
      • Zatvaranje u matični imenik nije prikladno jer je tamo teško organizirati pristup pisanja za druge korisnike
      • Korištenje simboličkih veza iz vašeg matičnog direktorija također je teško jer ih Git ne tumači kao veze
      • Moguće je ograničiti pristup tumaču, ali ne postoji potpuno jamstvo da će uvijek raditi
        • Općenito možete povezati vlastiti tumač naredbi za takve korisnike, ali
          • Prvo, ovo je već neka teška odluka,
          • i drugo, to se može zaobići.

    Ali možda nije problem da će korisnik moći izvršiti bilo koju naredbu?.. Općenito, ova se metoda ne može isključiti ako točno shvatite kako je koristiti. Kasnije ćemo se vratiti na ovu metodu, ali za sada ćemo ukratko razmotriti druge alternative, možda će biti nešto jednostavnije.

  • Git lokalni protokol se može koristiti u kombinaciji sa sshfs, može se koristiti više korisnika, ali u biti isto kao i prethodni slučaj
  • http - samo za čitanje
  • git je samo za čitanje
  • https - teško instalirati, potreban vam je dodatni softver, nekakva kontrolna ploča za organizaciju pristupa korisnika... izgleda izvedivo, ali nekako je sve komplicirano.

Korištenje ssh protokola za organizaciju višekorisničkog pristupa Git poslužitelju

Vratimo se na ssh protokol.

Budući da koristite ssh pristup za git, morate osigurati sigurnost podataka poslužitelja. Korisnik koji se povezuje putem ssh-a koristi vlastitu prijavu na Linux poslužitelju, tako da se može spojiti putem ssh klijenta i pristupiti naredbenoj liniji poslužitelja.
Ne postoji potpuna zaštita od takvog pristupa.

Ali korisnika ne bi trebale zanimati Linux datoteke. Značajne informacije pohranjuju se samo u git repozitorij. Stoga je moguće ne ograničiti pristup preko naredbenog retka, već pomoću Linux alata zabraniti korisniku pregled projekata, isključujući one u kojima sudjeluje.
Očigledan izbor je korištenje Linux sustava dopuštenja.

Kao što je već spomenuto, moguće je koristiti samo jedan račun za ssh pristup. Ova konfiguracija nije sigurna za nekoliko korisnika, iako je uključena u popis preporučenih git opcija.

Za provedbu zahtjeva navedenih na početku članka stvara se sljedeća struktura imenika s dodjelom prava i vlasnika:

1) imenici projekata

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
gdje
dir1, dir2, dir3 - direktoriji projekta: projekt 1, projekt 2, projekt 3.

proj1:proj1, proj2:proj2, proj3:proj3 su posebno stvoreni Linux korisnici koji su dodijeljeni kao vlasnici odgovarajućih direktorija projekta.

dozvole za sve imenike postavljene su na 0770 - potpuni pristup za vlasnika i njegovu grupu i potpuna zabrana za sve ostale.

2) računi programera

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

Ključna stvar je da se programerima dodjeljuje dodatna grupa korisnika sustava vlasnika odgovarajućeg projekta. To radi administrator Linux poslužitelja jednom naredbom.

U ovom primjeru, "Developer 1" radi na projektima proj1 i proj2, a "Developer 2" radi na projektima proj2 i proj3.

Ako se bilo koji od Programera poveže putem ssh-a preko naredbenog retka, tada njegova prava neće biti dovoljna čak ni za pregled sadržaja projektnih direktorija u kojima ne sudjeluju. On to sam ne može promijeniti.

Budući da je temelj ovog načela osnovna sigurnost Linux prava, ova je shema pouzdana. Osim toga, shema je vrlo jednostavna za administriranje.

Krenimo dalje u praksu.

Stvaranje Git repozitorija na Linux poslužitelju

Provjeravanje.

[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

Umorna sam od ručnog tipkanja...

[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

Uvjereni smo da je nemoguće pristupiti tuđim repozitoriju iz naredbenog retka, pa čak ni vidjeti njihov sadržaj.

[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

Surađujte s više programera na istom projektu u Gitu

Ostaje jedno pitanje, ako jedan programer uvede novu datoteku, onda je drugi programeri ne mogu promijeniti, jer je on sam njen vlasnik (na primjer, dev1), a ne korisnik vlasnik projekta (na primjer, proj1). Budući da imamo repozitorij na strani poslužitelja, prije svega moramo znati kako je strukturiran direktorij ".git" i stvaraju li se nove datoteke.

Stvaranje lokalnog Git spremišta i slanje na Git poslužitelj

Prijeđimo na klijentsko računalo.

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>

Istovremeno se stvaraju nove datoteke na poslužitelju, a pripadaju korisniku koji je izvršio 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]$

Kada uploadate promjene na Git server, stvaraju se dodatne datoteke i direktoriji, a njihov vlasnik je zapravo korisnik koji vrši upload. Ali tada grupa ovih datoteka i direktorija također odgovara glavnoj grupi ovog korisnika, to jest, grupi dev1 za korisnika dev1 i grupi dev2 za korisnika dev2 (promjena glavne grupe korisnika razvojnog programera neće pomoći, jer kako onda možete raditi na više projekata?). U tom slučaju korisnik dev2 neće moći mijenjati datoteke koje je izradio korisnik dev1, što bi moglo dovesti do kvara u funkcionalnosti.

Linux chown - promjena vlasnika datoteke od strane običnog korisnika

Vlasnik datoteke ne može promijeniti njezino vlasništvo. Ali on može promijeniti grupu datoteke koja mu pripada, a zatim ovu datoteku mogu mijenjati drugi korisnici koji su u istoj grupi. To je ono što nam treba.

Korištenje Git kuke

Radni direktorij za kuku je korijenski direktorij projekta. hook je izvršna datoteka koja se pokreće pod korisnikom koji vrši push. Znajući to, možemo provesti svoje planove.

[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

bilo samo 

vi hooks/post-update

Vratimo se klijentskom stroju.

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

Na Git poslužitelju provjeravamo rad zakačke skripte nakon ažuriranja nakon predaje 

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

- prazan, sve je u redu.

Povezivanje drugog programera u Gitu

Simulirajmo rad drugog programera.

Na klijentu

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

A u isto vrijeme, na serveru...

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

— opet prazno, sve radi.

Brisanje Git projekta i preuzimanje projekta s Git poslužitelja

Pa, možete se još jednom uvjeriti da su sve promjene spremljene.

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

— za brisanje Git projekta, jednostavno potpuno očistite direktorij. Pomirimo se s greškom koja se generira, budući da je nemoguće izbrisati trenutni direktorij pomoću ove naredbe, ali to je upravo ponašanje koje nam treba.

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"

Dijeljenje pristupa u Gitu

Sada osigurajmo da čak ni preko Gita drugi programer ne može pristupiti projektu Proj1, na kojem ne radi.

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.

Sada dopuštamo pristup

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

i nakon toga sve radi.

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

Za više informacija,

Osim toga, ako postoji problem sa zadanim dopuštenjima pri stvaranju datoteka i direktorija, u CentOS-u možete koristiti naredbu

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

Također u članku možete naići na male korisne stvari:

  • kako izgraditi stablo imenika u Linuxu
  • kako proslijediti raspon adresa u sed-u od određene linije do kraja datoteke, odnosno napraviti zamjenu u sed-u u svim linijama osim u prvoj liniji
  • Kako obrnuti uvjet pretraživanja u Linux find
  • Kako proslijediti više redaka u petlju koristeći jednoliner u Linux ljusci
  • Kako izbjeći jednostruke navodnike u bashu
  • kako izbrisati direktorij sa svim njegovim sadržajem u naredbenom retku windowsa
  • Kako koristiti bash mv za preimenovanje datoteke bez ponovnog pisanja

Hvala na pozornosti.

Izvor: www.habr.com

Dodajte komentar