ProHoster > Bloc > Administració > Organització de l'accés multiusuari al servidor GIT

Organització de l'accés multiusuari al servidor GIT

En instal·lar i configurar un servidor Git, sorgeix la qüestió d'organitzar l'accés de diversos usuaris a diversos projectes. Vaig fer una mica de recerca sobre el problema i vaig trobar una solució que s'adaptava a tots els meus requisits: senzilla, segura, fiable.

Els meus desitjos són:

  • cada usuari es connecta amb el seu propi compte
  • Diversos usuaris poden treballar en el mateix projecte
  • un mateix usuari pot treballar en diversos projectes
  • cada usuari només té accés als projectes en què treballa
  • hauria de ser possible connectar-se mitjançant la línia d'ordres, i no només mitjançant algun tipus d'interfície web

També seria genial:

  • concedir drets de només lectura a les persones que controlen
  • Administreu còmodament els permisos dels usuaris a Git

Visió general de les opcions possibles per accedir al servidor GIT

En primer lloc, heu de saber entre què triar, així que una breu visió general dels protocols Git.

  • ssh: s'utilitza un compte d'usuari creat especialment per accedir al servidor.
    • És estrany que Git no recomana utilitzar un compte per accedir a tots els dipòsits. Això no compleix en absolut els meus requisits.
    • Podeu utilitzar diversos comptes, però com podeu limitar l'accés d'un usuari només a determinats directoris?
      • Tancar-se al directori d'inici no és adequat, perquè és difícil organitzar l'accés d'escriptura per a altres usuaris allà
      • L'ús d'enllaços simbòlics del directori d'inici també és complicat perquè Git no els interpreta com a enllaços.
      • Restringeix l'accés a l'intèrpret, bé, pots, però no hi ha cap garantia total que això funcioni sempre
        • En general, podeu connectar el vostre propi intèrpret d'ordres per a aquests usuaris, però,
          • en primer lloc, aquesta ja és una mena de decisió difícil,
          • i 2, es pot ometre.

    Però potser no és un problema que l'usuari pugui executar cap ordre?... En general, aquest mètode no es pot descartar si esbrineu exactament com utilitzar-lo. Tornarem a aquest mètode més endavant, però de moment analitzarem breument la resta d'alternatives, potser hi haurà alguna cosa més senzilla.

  • El protocol local git es pot utilitzar en combinació amb sshfs, es poden utilitzar diversos usuaris, però és essencialment el mateix que el cas anterior
  • http - només lectura
  • git és només de lectura
  • https és difícil d'instal·lar, necessites programari addicional, algun tipus de panell de control per organitzar l'accés dels usuaris... sembla factible, però d'alguna manera tot és complicat.

Utilitzant el protocol ssh per organitzar l'accés multiusuari al servidor Git

Tornem al protocol ssh.

Com que s'utilitza l'accés ssh per a git, les dades del servidor han de ser segures. L'usuari que es connecta mitjançant ssh utilitza el seu propi inici de sessió al servidor Linux, de manera que es pot connectar mitjançant el client ssh i accedir a la línia d'ordres del servidor.
No hi ha una protecció completa contra aquest accés.

Però l'usuari no hauria d'interessar els fitxers Linux. La informació significativa només s'emmagatzema al repositori git. Per tant, no es pot restringir l'accés a través de la línia d'ordres, sinó que mitjançant Linux, prohibir a l'usuari visualitzar projectes, excloent aquells en què participa.
És obvi utilitzar el sistema de permisos Linux.

Com ja s'ha esmentat, només és possible utilitzar un compte per a l'accés ssh. Aquesta configuració no és segura per a diversos usuaris, tot i que s'inclou a la llista d'opcions recomanades de git.

Per implementar els requisits indicats al principi de l'article, es crea la següent estructura de directoris amb l'assignació de drets i propietaris:

1) directoris de projectes

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
on
dir1, dir2, dir3 - directoris del projecte: projecte 1, projecte 2, projecte 3.

proj1:proj1, proj2:proj2, proj3:proj3 són usuaris de Linux creats especialment que s'assignen com a propietaris dels directoris de projecte respectius.

els drets de tots els directoris s'estableixen en 0770: accés complet per al propietari i el seu grup, i prohibició total per a tots els altres.

2) comptes de desenvolupador

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

El punt clau és que als desenvolupadors se'ls assigna un grup addicional de l'usuari del sistema propietari del projecte corresponent. Això ho fa l'administrador del servidor Linux amb una ordre.

En aquest exemple, el desenvolupador 1 està treballant en els projectes proj1 i proj2, i el desenvolupador 2 està treballant en els projectes proj2 i proj3.

Si algun dels desenvolupadors es connecta mitjançant ssh a través de la línia d'ordres, els seus drets no seran suficients ni tan sols per veure el contingut dels directoris de projectes en què no participa. Ell mateix no pot canviar-ho.

Com que la base d'aquest principi és la seguretat bàsica dels drets de Linux, aquest esquema és fiable. A més, l'esquema és molt fàcil d'administrar.

Anem a practicar.

Creació de repositoris Git en un servidor Linux

Comprovem.

[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

cansat d'escriure...

[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

Estem convençuts que és impossible accedir als repositoris d'altres persones des de la línia d'ordres i fins i tot veure'n el contingut.

[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

Col·laboració en Git de diversos desenvolupadors en un projecte

Queda una pregunta: si un desenvolupador introdueix un fitxer nou, altres desenvolupadors no el poden canviar, perquè ell mateix n'és el propietari (per exemple, dev1) i no l'usuari propietari del projecte (per exemple, proj1). Com que tenim un repositori de servidor, primer de tot, hem de saber com està disposat el directori “.git” i si es creen nous fitxers.

Creeu un repositori Git local i envieu-lo a un servidor Git

Passem a la màquina client.

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>

Al mateix temps, es generen nous fitxers al servidor i pertanyen a l'usuari que ha realitzat l'empenta

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

Quan es carreguen els canvis al servidor Git, es creen fitxers i directoris addicionals que són propietat de l'encarregat de pujar. Però aleshores el grup d'aquests fitxers i directoris també correspon al grup principal d'aquest usuari, és a dir, el grup dev1 per a l'usuari dev1 i el grup dev2 per a l'usuari dev2 (canviar el grup principal de l'usuari desenvolupador no ajudarà, perquè llavors com treballar en múltiples projectes?). En aquest cas, l'usuari dev2 no podrà modificar els fitxers creats per l'usuari dev1, i això està ple d'una violació de la funcionalitat.

Linux chown: canvia el propietari d'un fitxer per part d'un usuari normal

El propietari d'un fitxer no pot canviar-ne la propietat. Però pot canviar el grup d'un fitxer que li pertany, i després aquest fitxer pot ser modificat per altres usuaris que estiguin al mateix grup. Això és el que necessitem.

Utilitzant el Git Hook

El directori de treball per a hook és el directori arrel del projecte. hook és un executable que s'executa sota l'usuari que fa l'empenta. sabent això, podem dur a terme els nostres plans.

[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

o bé només 

vi hooks/post-update

Tornem a la màquina client.

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

Al servidor Git, comproveu el treball de l'script posterior a l'actualització del ganxo després de la confirmació 

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

- buit, tot està bé.

Connectant un segon desenvolupador a Git

Simulem el treball del segon desenvolupador.

Sobre el client

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

I alhora, al servidor...

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

- de nou buit, tot funciona.

Suprimir un projecte Git i carregar un projecte des d'un servidor Git

Bé, podeu tornar a assegurar-vos que tots els canvis s'han desat.

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

- per eliminar un projecte Git, simplement esborreu el directori completament. Suportem l'error donat, ja que és impossible esborrar el directori actual amb aquesta ordre, però aquest és exactament el comportament que necessitem.

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"

Compartint l'accés a Git

Ara assegurem-nos que el segon desenvolupador no pot accedir al projecte Proj1 a través de Git, en el qual no treballa.

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.

Ara permet l'accés

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

i després tot funciona.

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

Per obtenir més informació,

A més, si hi ha un problema amb els permisos predeterminats en crear fitxers i directoris, a CentOS podeu utilitzar l'ordre

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

També a l'article podeu ensopegar amb petites coses útils:

  • com construir un arbre de directoris a Linux
  • com passar un rang d'adreces des d'una línia determinada fins al final del fitxer a sed, és a dir, fer un reemplaçament en sed a totes les línies excepte a la primera línia
  • Com invertir la condició de cerca a la cerca de Linux
  • com passar diverses línies a través d'una sola línia en un shell de Linux
  • com escapar de cometes simples a bash
  • com esborrar un directori amb tot el contingut a la línia d'ordres de Windows
  • Com canviar el nom d'un fitxer amb bash mv sense tornar-lo a escriure

Gràcies per la seva atenció.

Font: www.habr.com

Afegeix comentari