ProHoster > Blogi > antaminen > Monen käyttäjän pääsyn järjestäminen GIT-palvelimelle

Monen käyttäjän pääsyn järjestäminen GIT-palvelimelle

Git-palvelinta asennettaessa ja konfiguroitaessa herää kysymys useiden käyttäjien pääsyn järjestämisestä useisiin projekteihin. Tutkin asiaa hieman ja löysin ratkaisun, joka täyttää kaikki vaatimukset: yksinkertainen, turvallinen, luotettava.

Toiveeni ovat:

  • jokainen käyttäjä muodostaa yhteyden omaan tiliinsä
  • Useat käyttäjät voivat työskennellä saman projektin parissa
  • sama käyttäjä voi työskennellä useissa projekteissa
  • jokaisella käyttäjällä on pääsy vain niihin projekteihin, joissa hän työskentelee
  • yhteyden pitäisi olla mahdollista komentorivin kautta, ei vain jonkin web-käyttöliittymän kautta

Olisi myös hienoa:

  • myöntää määräysvaltaa käyttäville henkilöille vain lukuoikeudet
  • hallita kätevästi käyttäjien käyttöoikeuksia Gitissä

Yleiskatsaus mahdollisista GIT-palvelimen käyttövaihtoehdoista

Ensinnäkin sinun on tiedettävä, mistä valita, joten lyhyt katsaus Git-protokolliin.

  • ssh - palvelimelle pääsyyn käytetään erityisesti luotua käyttäjätiliä.
    • On outoa, että Git ei suosittele olemaan käyttämättä yhtä tiliä kaikkien tietovarastojen käyttämiseen. Tämä ei täytä vaatimuksiani ollenkaan.
    • Voit käyttää useita tilejä, mutta kuinka voit rajoittaa käyttäjän pääsyä vain tiettyihin hakemistoihin?
      • Kotihakemiston sulkeminen ei sovellu, koska siellä on vaikea järjestää kirjoitusoikeuksia muille käyttäjille
      • Symbolisten linkkien käyttäminen kotihakemistosta on myös hankalaa, koska Git ei tulkitse niitä linkeiksi.
      • Voit rajoittaa tulkin pääsyä, mutta ei ole täyttä takuuta, että tämä toimii aina
        • Voit yleensä yhdistää oman komentotulkin tällaisille käyttäjille, mutta
          • Ensinnäkin tämä on jo jonkinlainen vaikea päätös,
          • ja 2, se voidaan ohittaa.

    Mutta ehkä se ei ole ongelma, että käyttäjä pystyy suorittamaan mitä tahansa komentoja? .. Yleensä tätä menetelmää ei voida sulkea pois, jos selvittää tarkalleen kuinka sitä käytetään. Palaamme tähän menetelmään myöhemmin, mutta toistaiseksi harkitsemme lyhyesti jäljellä olevia vaihtoehtoja, ehkä siellä on jotain yksinkertaisempaa.

  • git paikallista protokollaa voidaan käyttää yhdessä sshfs:n kanssa, useita käyttäjiä voidaan käyttää, mutta se on olennaisesti sama kuin edellinen tapaus
  • http - vain luku
  • git on vain luku -tilassa
  • https on vaikea asentaa, tarvitset lisäohjelmistoa, jonkinlaisen ohjauspaneelin käyttäjien pääsyn järjestämiseen ... näyttää mahdolliselta, mutta jotenkin kaikki on monimutkaista.

Ssh-protokollan käyttäminen järjestää usean käyttäjän pääsy Git-palvelimelle

Palataan ssh-protokollaan.

Koska ssh-käyttöä käytetään gitissä, palvelintietojen on oltava suojattuja. Ssh:n kautta yhteyden muodostava käyttäjä käyttää omaa kirjautumistaan ​​Linux-palvelimelle, joten hän voi muodostaa yhteyden ssh-asiakkaan kautta ja käyttää palvelimen komentoriviä.
Täydellistä suojaa tällaista pääsyä vastaan ​​ei ole.

Mutta käyttäjän ei pitäisi olla kiinnostunut Linux-tiedostoista. Merkittävät tiedot tallennetaan vain git-tietovarastoon. Siksi et voi rajoittaa pääsyä komentorivin kautta, mutta Linuxin avulla voit estää käyttäjää katselemasta projekteja, pois lukien ne, joihin hän osallistuu.
On ilmeistä käyttää Linuxin käyttöoikeusjärjestelmää.

Kuten jo mainittiin, on mahdollista käyttää vain yhtä tiliä ssh-käyttöön. Tämä kokoonpano on vaarallinen useille käyttäjille, vaikka se sisältyykin gitin suositeltujen vaihtoehtojen luetteloon.

Artikkelin alussa annettujen vaatimusten toteuttamiseksi luodaan seuraava hakemistorakenne oikeuksilla ja omistajilla:

1) projektihakemistot

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
missä
dir1, dir2, dir3 - projektihakemistot: projekti 1, projekti 2, projekti 3.

proj1:proj1, proj2:proj2, proj3:proj3 ovat erityisesti luotuja Linux-käyttäjiä, jotka on määritetty vastaavien projektihakemistojen omistajiksi.

oikeudet kaikkiin hakemistoihin on asetettu arvoon 0770 - täydellinen pääsy omistajalle ja hänen ryhmälleen ja täydellinen kielto kaikille muille.

2) kehittäjätilit

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

Keskeinen asia on, että kehittäjille osoitetaan ylimääräinen ryhmä järjestelmän käyttäjiä, jotka omistavat vastaavan projektin. Tämän tekee Linux-palvelimen järjestelmänvalvoja yhdellä komennolla.

Tässä esimerkissä kehittäjä 1 työskentelee projekteissa proj1 ja proj2, ja kehittäjä 2 työskentelee projekteissa proj2 ja proj3.

Jos joku kehittäjistä muodostaa yhteyden ssh:n kautta komentorivin kautta, hänen oikeutensa eivät riitä edes katsomaan sellaisten projektien hakemistojen sisältöä, joihin hän ei osallistu. Hän ei voi muuttaa sitä itse.

Koska tämän periaatteen perustana on Linux-oikeuksien perusturva, tämä järjestelmä on luotettava. Lisäksi järjestelmää on erittäin helppo hallita.

Siirrymme käytäntöön.

Git-varastojen luominen Linux-palvelimelle

Tarkistamme.

[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

väsynyt kirjoittamaan...

[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

Olemme vakuuttuneita siitä, että on mahdotonta päästä muiden ihmisten arkistoihin komentoriviltä ja edes tarkastella niiden sisältöä.

[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

Useiden kehittäjien yhteistyö Gitissä yhdessä projektissa

Yksi kysymys jää, jos yksi kehittäjä ottaa käyttöön uuden tiedoston, muut kehittäjät eivät voi muuttaa sitä, koska hän itse on sen omistaja (esim. dev1), eikä projektin omistava käyttäjä (esimerkiksi proj1). Koska meillä on palvelinvarasto, meidän on ensinnäkin tiedettävä, miten ".git"-hakemisto on järjestetty ja luodaanko uusia tiedostoja.

Luo paikallinen Git-arkisto ja työnnä se Git-palvelimelle

Siirrytään asiakaskoneeseen.

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>

Samaan aikaan palvelimelle luodaan uusia tiedostoja, jotka kuuluvat työnnön suorittaneelle käyttäjälle

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

Kun muutokset ladataan Git-palvelimelle, luodaan lisää tiedostoja ja hakemistoja, jotka itse asiassa omistavat latauksen tekevä käyttäjä. Mutta sitten näiden tiedostojen ja hakemistojen ryhmä vastaa myös tämän käyttäjän pääryhmää, eli ryhmää dev1 käyttäjälle dev1 ja ryhmää dev2 käyttäjälle dev2 (kehittäjäkäyttäjän pääryhmän muuttaminen ei auta, koska silloin kuinka työskennellä useissa projekteissa?). Tässä tapauksessa dev2-käyttäjä ei voi muokata dev1-käyttäjän luomia tiedostoja, ja tämä on täynnä toiminnallisuuden rikkomista.

Linux chown - tiedoston omistajan vaihtaminen tavallisen käyttäjän toimesta

Tiedoston omistaja ei voi muuttaa sen omistajuutta. Mutta hän voi vaihtaa hänelle kuuluvan tiedoston ryhmän, ja sitten muut samassa ryhmässä olevat käyttäjät voivat muuttaa tätä tiedostoa. Sitä me tarvitsemme.

Git Hookin käyttäminen

Hookin työhakemisto on projektin juurihakemisto. hook on suoritettava tiedosto, joka toimii työntöä tekevän käyttäjän alla. Tämän tietäen voimme toteuttaa suunnitelmamme.

[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

tai vain 

vi hooks/post-update

Palataanpa asiakaskoneeseen.

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

Tarkista Git-palvelimella hook-päivityksen jälkeisen komentosarjan toiminta commitin jälkeen 

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

- tyhjä, kaikki on hyvin.

Toisen kehittäjän yhdistäminen Gitiin

Simuloitetaan toisen kehittäjän työtä.

Asiakkaan päällä

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

Ja samaan aikaan palvelimella...

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

- jälleen tyhjä, kaikki toimii.

Git-projektin poistaminen ja projektin lataaminen Git-palvelimelta

No, voit jälleen varmistaa, että kaikki muutokset on tallennettu.

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

- Jos haluat poistaa Git-projektin, tyhjennä hakemisto kokonaan. Ymmärrämme annettua virhettä, koska nykyisen hakemiston poistaminen tällä komennolla on mahdotonta, mutta juuri tällaista toimintaa tarvitsemme.

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"

Käyttöoikeuden jakaminen Gitissä

Varmistetaan nyt, että toinen kehittäjä ei pääse Proj1-projektiin Gitin kautta, jolla hän ei työskentele.

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.

Salli nyt pääsy

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

ja sen jälkeen kaikki toimii.

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

Lisätietoja

Lisäksi, jos oletusoikeuksissa on ongelmia tiedostoja ja hakemistoja luotaessa, CentOS:ssä voit käyttää komentoa

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

Myös artikkelissa voit törmätä pieniin hyödyllisiin asioihin:

  • kuinka rakentaa hakemistopuu Linuxissa
  • kuinka siirtää osoitealue tietystä rivistä tiedoston loppuun sed-muodossa, eli korvata sed:llä kaikilla riveillä paitsi ensimmäisellä rivillä
  • Kuinka kääntää hakuehto Linux-haussa
  • kuinka siirtää useita rivejä yhden rivin läpi Linux-kuoressa
  • kuinka välttää yksittäisiä lainausmerkkejä bashissa
  • kuinka poistaa hakemisto, jossa on kaikki sisältö Windowsin komentoriviltä
  • Kuinka nimetä tiedosto uudelleen käyttämällä bash mv:tä kirjoittamatta sitä uudelleen

Kiitos huomiota.

Lähde: will.com

Lisää kommentti