ProHoster > blogg > administration > Organisation av åtkomst för flera användare till GIT-servern

Organisation av åtkomst för flera användare till GIT-servern

När du installerar och konfigurerar en Git-server uppstår frågan om att organisera åtkomst för flera användare till flera projekt. Jag undersökte problemet och hittade en lösning som uppfyllde alla mina krav: enkel, säker, pålitlig.

Mina önskemål är:

  • varje användare ansluter till sitt eget konto
  • Flera användare kan arbeta med ett projekt
  • samma användare kan arbeta med flera projekt
  • varje användare har endast tillgång till de projekt som han arbetar med
  • Det ska vara möjligt att ansluta via kommandoraden, och inte bara genom något slags webbgränssnitt

Det skulle också vara bra:

  • ge läsbehörigheter till kontrollerande personer
  • Hantera användarens åtkomsträttigheter bekvämt i Git

Översikt över möjliga alternativ för åtkomst till GIT-servern

Först och främst måste du veta vad du ska välja mellan, så här är en snabb översikt över Git-protokoll.

  • ssh - ett speciellt skapat användarkonto används för att komma åt servern.
    • Det är konstigt att Git inte utesluter från sina rekommendationer användningen av ett konto för att komma åt alla arkiv. Detta uppfyller inte alls mina krav.
    • Du kan använda flera konton, men hur kan du begränsa användaråtkomst till endast vissa kataloger?
      • Att stänga in i hemkatalogen är inte lämpligt, eftersom det är svårt att organisera skrivåtkomst där för andra användare
      • Att använda symboliska länkar från din hemkatalog är också svårt eftersom Git inte tolkar dem som länkar
      • Det är möjligt att begränsa tillgången till tolken, men det finns ingen full garanti för att det alltid fungerar
        • Du kan i allmänhet ansluta din egen kommandotolk för sådana användare, men
          • För det första är detta redan något slags svårt beslut,
          • och för det andra kan detta kringgås.

    Men det kanske inte är ett problem att användaren kommer att kunna utföra några kommandon?.. Generellt sett kan denna metod inte uteslutas om du kommer på exakt hur den ska användas. Vi kommer att återkomma till den här metoden senare, men för nu ska vi kort överväga de andra alternativen, kanske kommer det att finnas något enklare.

  • Det lokala git-protokollet kan användas i kombination med sshfs, flera användare kan användas, men i huvudsak samma som föregående fall
  • http - skrivskyddad
  • git är skrivskyddad
  • https - svårt att installera, du behöver ytterligare programvara, någon form av kontrollpanel för att organisera användaråtkomst... det ser möjligt ut, men på något sätt är allt komplicerat.

Använder ssh-protokollet för att organisera åtkomst för flera användare till Git-servern

Låt oss återgå till ssh-protokollet.

Eftersom du använder ssh-åtkomst för git måste du säkerställa säkerheten för serverdata. Användaren som ansluter via ssh använder sin egen inloggning på Linux-servern, så att de kan ansluta via ssh-klienten och komma åt serverns kommandorad.
Det finns inget fullständigt skydd mot sådan åtkomst.

Men användaren ska inte vara intresserad av Linux-filer. Betydande information lagras endast i git-förvaret. Därför är det möjligt att inte begränsa åtkomsten via kommandoraden, utan att använda Linux-verktyg för att förbjuda användaren att se projekt, exklusive de som han deltar i.
Det självklara valet är att använda Linux-behörighetssystemet.

Som redan nämnts är det möjligt att endast använda ett konto för ssh-åtkomst. Denna konfiguration är osäker för flera användare, även om den ingår i listan över rekommenderade git-alternativ.

För att implementera kraven som anges i början av artikeln skapas följande katalogstruktur med tilldelning av rättigheter och ägare:

1) projektkataloger

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
.
där
dir1, dir2, dir3 - projektkataloger: projekt 1, projekt 2, projekt 3.

proj1:proj1, proj2:proj2, proj3:proj3 är speciellt skapade Linux-användare som tilldelas som ägare av motsvarande projektkataloger.

behörigheter för alla kataloger är inställda på 0770 - full åtkomst för ägaren och hans grupp och ett fullständigt förbud för alla andra.

2) utvecklarkonton

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

Nyckelpunkten är att utvecklare tilldelas en extra grupp av systemanvändarens ägare av motsvarande projekt. Detta görs av Linux-serveradministratören med ett kommando.

I det här exemplet arbetar "Utvecklare 1" med projekten proj1 och proj2, och "Utvecklare 2" arbetar med projekten proj2 och proj3.

Om någon av utvecklarna ansluter via ssh via kommandoraden, kommer deras rättigheter inte att räcka ens för att se innehållet i projektkataloger som de inte deltar i. Han kan inte ändra på detta själv.

Eftersom grunden för denna princip är den grundläggande säkerheten för Linux-rättigheter, är detta schema tillförlitligt. Dessutom är schemat mycket lätt att administrera.

Låt oss fortsätta träna.

Skapa Git-förråd på en Linux-server

Vi kollar.

[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

Jag är trött på att skriva för hand...

[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

Vi är övertygade om att det är omöjligt att komma åt andras arkiv från kommandoraden och till och med se deras innehåll.

[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

Samarbeta med flera utvecklare i samma projekt i Git

En fråga kvarstår, om en utvecklare introducerar en ny fil, kan andra utvecklare inte ändra den, eftersom han själv är dess ägare (till exempel dev1), och inte användarens ägare av projektet (till exempel proj1). Eftersom vi har ett arkiv på serversidan måste vi först och främst veta hur ".git"-katalogen är uppbyggd och om nya filer skapas.

Skapa ett lokalt Git-förråd och skjuta till Git-servern

Låt oss gå vidare till klientmaskinen.

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>

Samtidigt skapas nya filer på servern, och de tillhör användaren som utförde pushen

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

När du laddar upp ändringar till Git-servern skapas ytterligare filer och kataloger, och deras ägare är faktiskt användaren som gör uppladdningen. Men då motsvarar gruppen av dessa filer och kataloger också huvudgruppen för denna användare, det vill säga dev1-gruppen för dev1-användaren och dev2-gruppen för dev2-användaren (det hjälper inte att ändra huvudgruppen för utvecklaranvändaren, för hur kan du då arbeta med flera projekt?). I det här fallet kommer användaren dev2 inte att kunna ändra filer som skapats av användaren dev1, vilket kan leda till funktionsavbrott.

Linux chown - ändra ägare till en fil av en vanlig användare

Ägaren till en fil kan inte ändra dess ägande. Men han kan ändra gruppen för en fil som tillhör honom, och sedan kan den här filen ändras av andra användare som är i samma grupp. Det är vad vi behöver.

Använder Git hook

Arbetskatalogen för hook är projektets rotkatalog. hook är en körbar fil som körs under användaren som gör pushen. Genom att veta detta kan vi genomföra våra planer.

[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

eller bara 

vi hooks/post-update

Låt oss återgå till klientmaskinen.

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

På Git-servern kontrollerar vi funktionen för hook post-update script efter commit 

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

- tomt, allt är bra.

Ansluter en andra utvecklare i Git

Låt oss simulera den andra utvecklarens arbete.

På klienten

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

Och samtidigt på servern...

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

— tomt igen, allt fungerar.

Ta bort ett Git-projekt och ladda ner projektet från Git-servern

Tja, du kan återigen se till att alla ändringar har sparats.

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

— för att ta bort ett Git-projekt, rensa helt enkelt katalogen helt. Låt oss stå ut med felet som genereras, eftersom det är omöjligt att ta bort den aktuella katalogen med det här kommandot, men det är precis det beteende vi behöver.

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"

Delar åtkomst i Git

Låt oss nu se till att även genom Git inte kan den andra utvecklaren komma åt Proj1-projektet, som han inte arbetar med.

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.

Nu tillåter vi åtkomst

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

och efter det fungerar allt.

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

För mer information,

Dessutom, om det finns ett problem med standardbehörigheterna när du skapar filer och kataloger, i CentOS kan du använda kommandot

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

Även i artikeln kan du snubbla på små användbara saker:

  • hur man bygger ett katalogträd i Linux
  • hur man skickar ett intervall av adresser i sed från en viss rad till slutet av filen, det vill säga gör en ersättning i sed på alla rader utom den första raden
  • Hur man inverterar ett sökvillkor i Linux-sök
  • Hur man skickar flera rader till en loop med en one-liner i Linux-skalet
  • Hur man undkommer enstaka citattecken i bash
  • hur man tar bort en katalog med allt dess innehåll på kommandoraden i Windows
  • Hur man använder bash mv för att byta namn på en fil utan att skriva om den igen

Tack för er uppmärksamhet.

Källa: will.com

Lägg en kommentar