Организация на многопотребителски достъп до GIT сървъра

Когато инсталирате и конфигурирате Git сървър, възниква въпросът за организиране на достъп за няколко потребители до няколко проекта. Проучих малко по въпроса и намерих решение, което отговаря на всичките ми изисквания: просто, безопасно, надеждно.

Моите желания са:

• всеки потребител се свързва със собствен акаунт
• Множество потребители могат да работят по един и същ проект
• един и същ потребител може да работи върху множество проекти
• всеки потребител има достъп само до онези проекти, върху които работи
• трябва да е възможно да се свържете през командния ред, а не само чрез някакъв уеб интерфейс

Също така би било чудесно:

• дават права само за четене на контролиращи лица
• удобно администриране на потребителски разрешения в Git

Преглед на възможните опции за достъп до GIT сървъра

На първо място, трябва да знаете от какво да избирате, така че кратък преглед на протоколите на Git.

• ssh - за достъп до сървъра се използва специално създаден потребителски акаунт.
  • странно е, че Git не препоръчва използването на един акаунт за достъп до всички хранилища. Това изобщо не отговаря на изискванията ми.
  • Можете да използвате няколко акаунта, но как можете да ограничите достъпа на потребителя само до определени директории?
    • Затварянето в домашната директория не е подходящо, защото е трудно да се организира достъп за писане за други потребители там
    • Използването на символни връзки от началната директория също е трудно, защото Git не ги интерпретира като връзки.
    • Ограничете достъпа до преводача, добре, можете, но няма пълна гаранция, че това винаги ще работи
      • По принцип можете да свържете свой собствен команден интерпретатор за такива потребители, но,
        • първо, това вече е някакво трудно решение,
        • и 2, може да бъде прескочен.

  Но може би не е проблем, че потребителят ще може да изпълнява всякакви команди? .. Като цяло този метод не може да бъде изключен, ако разберете как точно да го използвате. Ще се върнем към този метод по-късно, но засега ще разгледаме накратко останалите алтернативи, може би ще има нещо по-просто.

• git локален протокол може да се използва в комбинация с sshfs, могат да се използват множество потребители, но по същество е същият като предишния случай
• http - само за четене
• git е само за четене
• https е труден за инсталиране, трябва ви допълнителен софтуер, някакъв контролен панел за организиране на потребителския достъп ... изглежда осъществимо, но някак си всичко е сложно.

Използване на ssh протокола за организиране на многопотребителски достъп до Git сървъра

Да се ​​върнем на ssh протокола.

Тъй като ssh достъпът се използва за git, данните на сървъра трябва да бъдат защитени. Потребителят, който се свързва чрез ssh, използва собствените си данни за влизане в сървъра на Linux, така че да може да се свързва чрез ssh клиента и да има достъп до командния ред на сървъра.
Няма пълна защита срещу получаване на такъв достъп.

Но потребителят не трябва да се интересува от Linux файлове. Смислената информация се съхранява само в git хранилището. Следователно не можете да ограничите достъпа чрез командния ред, но с помощта на Linux забранете на потребителя да преглежда проекти, с изключение на тези, в които той участва.
Очевидно е да използвате системата за разрешения на Linux.

Както вече споменахме, възможно е да използвате само един акаунт за ssh достъп. Тази конфигурация не е безопасна за няколко потребители, въпреки че е включена в списъка с препоръчани опции на git.

За изпълнение на изискванията, дадени в началото на статията, се създава следната структура на директория с присвояване на права и собственици:

1) директории на проекти

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
където
dir1, dir2, dir3 - директории на проекти: проект 1, проект 2, проект 3.

proj1:proj1, proj2:proj2, proj3:proj3 са специално създадени потребители на Linux, които са назначени като собственици на съответните директории на проекта.

правата за всички директории са зададени на 0770 - пълен достъп за собственика и неговата група и пълен бан за всички останали.

2) акаунти на разработчици

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

Ключовият момент е, че на разработчиците се присвоява допълнителна група от потребители на системата, които притежават съответния проект. Това се прави от администратора на Linux сървъра с една команда.

В този пример Разработчик 1 работи върху проекти proj1 и proj2, а Разработчик 2 работи върху проекти proj2 и proj3.

Ако някой от разработчиците се свърже чрез ssh чрез командния ред, тогава неговите права няма да са достатъчни дори за преглед на съдържанието на директориите на проекти, в които той не участва. Той не може да го промени сам.

Тъй като основата на този принцип е основната сигурност на правата на Linux, тази схема е надеждна. Освен това схемата е много лесна за администриране.

Нека да продължим да практикуваме.

Създаване на Git хранилища на Linux сървър

Проверяваме.

[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

уморен от писане...

[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

Убедени сме, че е невъзможно да получите достъп до хранилищата на други хора от командния ред и дори да видите тяхното съдържание.

[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

Сътрудничество в Git на няколко разработчици по един проект

Остава един въпрос, ако един разработчик въведе нов файл, тогава други разработчици не могат да го променят, защото самият той е негов собственик (например dev1), а не потребителят, който притежава проекта (например proj1). Тъй като имаме сървърно хранилище, първо трябва да знаем как е подредена директорията „.git“ и дали се създават нови файлове.

Създайте локално хранилище на Git и насочете към Git сървър

Да преминем към клиентската машина.

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>

В същото време на сървъра се генерират нови файлове и те принадлежат на потребителя, извършил натискането

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

Когато промените се качват на Git сървъра, се създават допълнителни файлове и директории, които всъщност са собственост на качващия. Но тогава групата от тези файлове и директории също съответства на основната група на този потребител, тоест групата dev1 за потребителя dev1 и групата dev2 за потребителя dev2 (промяната на основната група на потребителя разработчик няма да помогне, защото тогава как да работим по множество проекти?). В този случай потребителят dev2 няма да може да променя файловете, създадени от потребителя dev1, и това е изпълнено с нарушаване на функционалността.

Linux chown - смяна на собственика на файл от нормален потребител

Собственикът на файл не може да промени собствеността му. Но той може да промени групата на файл, който му принадлежи, и след това този файл може да бъде променен от други потребители, които са в същата група. Това ни трябва.

Използване на Git Hook

Работната директория за hook е основната директория на проекта. hook е изпълним файл, който се изпълнява от потребителя, който извършва натискането. знаейки това, можем да осъществим плановете си.

[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

или просто

vi hooks/post-update

Да се ​​върнем на клиентската машина.

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 проверете работата на скрипта за кука след актуализиране след ангажимента

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

- празно, всичко е наред.

Свързване на втори разработчик към Git

Нека симулираме работата на втория разработчик.

На клиента

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

И в същото време на сървъра...

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

- отново празен, всичко работи.

Изтриване на Git проект и зареждане на проект от Git сървър

Е, можете отново да се уверите, че всички промени са запазени.

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

- за да премахнете Git проект, просто изчистете напълно директорията. Нека се примирим с дадената грешка, тъй като е невъзможно да изтриете текущата директория с тази команда, но това е точно поведението, от което се нуждаем.

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"

Споделяне на достъп в Git

Сега нека се уверим, че вторият разработчик няма достъп до проекта Proj1 чрез Git, върху който той не работи.

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.

Сега разрешете достъп

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

и след това всичко работи.

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

За повече информация

Освен това, ако има проблем с разрешенията по подразбиране при създаване на файлове и директории, в CentOS можете да използвате командата

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

Също така в статията можете да се натъкнете на малки полезни неща:

• как да изградите дърво на директории в linux
• как да прехвърлите диапазон от адреси от определен ред до края на файла в sed, тоест да направите замяна в sed във всички редове с изключение на първия ред
• Как да обърна условието за търсене в Linux find
• как да прекарате няколко реда през едноредов в linux shell
• как да избегнете единични кавички в bash
• как да изтриете директория с цялото съдържание в командния ред на windows
• Как да преименувате файл с помощта на bash mv, без да го пренаписвате

Благодаря ви за вниманието.

Източник: www.habr.com