Организација на повеќекориснички пристап до серверот GIT

При инсталирање и конфигурирање на Git сервер, се поставува прашањето за организирање пристап за неколку корисници до неколку проекти. Го истражував проблемот и најдов решение што ги исполнува сите мои барања: едноставно, безбедно, сигурно.

Моите желби се:

• секој корисник се поврзува со своја сметка
• Неколку корисници можат да работат на еден проект
• истиот корисник може да работи на повеќе проекти
• секој корисник има пристап само до оние проекти на кои работи
• Треба да биде можно да се поврзете преку командната линија, а не само преку некој вид веб-интерфејс

Исто така би било одлично:

• давање дозволи само за читање на контролните лица
• Погодно управувајте со правата за пристап на корисниците во Git

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

Пред сè, треба да знаете од што да изберете, па затоа еве брз преглед на протоколите Git.

• ssh - специјално креирана корисничка сметка се користи за пристап до серверот.
  • Чудно е што Git не ја исклучува од своите препораки користењето на една сметка за пристап до сите складишта. Ова воопшто не ги задоволува моите барања.
  • Можете да користите повеќе сметки, но како можете да го ограничите корисничкиот пристап само до одредени директориуми?
    • Затворањето во домашниот директориум не е соодветно, бидејќи е тешко да се организира пристап за пишување таму за други корисници
    • Користењето симболи од вашиот домашен директориум е исто така тешко бидејќи Git не ги толкува како врски
    • Можно е да се ограничи пристапот до преведувачот, но не постои целосна гаранција дека тој секогаш ќе работи
      • Генерално можете да поврзете сопствен преведувач на команди за такви корисници, но
        • прво, ова е веќе некаква тешка одлука,
        • и второ, ова може да се заобиколи.

  Но, можеби не е проблем што корисникот ќе може да изврши какви било команди?.. Во принцип, овој метод не може да се исклучи ако точно сфатите како да го користите. На овој метод ќе се вратиме подоцна, но засега накратко ќе ги разгледаме другите алтернативи, можеби ќе има нешто поедноставно.

• Локалниот протокол 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

Клучната точка е што на програмерите им е доделена дополнителна група на сопственикот на корисникот на системот на соодветниот проект. Ова го прави администраторот на серверот Линукс со една команда.

Во овој пример, „Developer 1“ работи на проектите proj1 и proj2, а „Developer 2“ работи на проектите proj2 и proj3.

Ако некој од Програмерите се поврзе преку ssh преку командната линија, тогаш нивните права нема да бидат доволни дури ни за прегледување на содржината на проектните директориуми во кои не учествуваат. Тој самиот не може да го промени ова.

Бидејќи основата на овој принцип е основната безбедност на правата на Линукс, оваа шема е сигурна. Покрај тоа, шемата е многу лесна за администрирање.

Ајде да одиме на пракса.

Креирање складишта на 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

Работниот директориум за кука е root директориумот на проектот. кука е извршна датотека што работи под корисникот кој врши притискање. Знаејќи го ова, можеме да ги спроведеме нашите планови.

[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

Сега да се увериме дека и преку Git вториот развивач не може да пристапи до проектот Proj1, на кој не работи.

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
• Како да поминете повеќе линии во јамка користејќи еднослојно во школката на Linux
• Како да избегате од единечни цитати во баш
• како да избришете директориум со целата негова содржина во командната линија на Windows
• Како да користите bash mv за преименување на датотека без повторно да ја препишете

Ви благодариме за вашето внимание.

Извор: www.habr.com