Organisation des Mehrbenutzerzugriffs auf den GIT-Server

Bei der Installation und Konfiguration eines Git-Servers stellt sich die Frage, wie der Zugriff mehrerer Benutzer auf mehrere Projekte organisiert werden kann. Ich habe das Thema untersucht und eine Lösung gefunden, die all meinen Anforderungen entspricht: einfach, sicher, zuverlässig.

Meine Anforderungen sind folgende:

• Jeder Benutzer meldet sich mit seinem eigenen Konto an.
• An einem Projekt können mehrere Benutzer arbeiten.
• Der gleiche Benutzer kann an mehreren Projekten arbeiten.
• Jeder Benutzer hat nur Zugriff auf die Projekte, an denen er arbeitet.
• Es sollte möglich sein, über die Kommandozeile zuzugreifen und nicht nur über eine Weboberfläche.

Es wäre auch großartig:

• Lesezugriff nur für Aufsichtspersonen zu gewähren.
• Benutzerrechte in Git bequem zu verwalten.

Übersicht über mögliche Zugriffsoptionen auf dem GIT-Server.

Zunächst muss man wissen, aus was man wählen kann, daher eine kurze Übersicht über die Git-Protokolle.

• ssh - Ein speziell angelegtes Benutzerkonto wird für den Zugriff auf den Server verwendet.
  • Es ist seltsam, dass Git in seinen Empfehlungen nicht ausschließt, ein einziges Konto für den Zugriff auf alle Repositories zu verwenden. Das entspricht meinen Anforderungen nicht.
  • Es können mehrere Konten verwendet werden, aber wie kann der Zugriff eines Benutzers auf bestimmte Verzeichnisse beschränkt werden?
    • Das Schließen in das Heimatverzeichnis ist nicht geeignet, da es schwierig ist, dort Schreibzugang für andere Benutzer zu organisieren.
    • Die Verwendung von symbolischen Links aus dem Heimatverzeichnis ist ebenfalls schwierig, weil Git sie nicht als Links interpretiert.
    • Den Zugriff auf den Interpreter einzuschränken ist möglich, aber es gibt keine vollständige Garantie, dass das immer funktioniert.
      • Man kann den Benutzern sogar ihren eigenen Befehlsinterpreter zur Verfügung stellen, aber:
        • Erstens, das ist schon eine komplizierte Lösung.
        • Zweitens, das kann umgangen werden.

  Aber vielleicht ist es kein Problem, dass Benutzer beliebige Befehle ausführen können? ... Insgesamt sollte man diese Methode nicht ausschließen, wenn man sich überlegt, wie man sie genau einsetzen kann. Lassen Sie uns später zu dieser Methode zurückkehren, und währenddessen betrachten wir kurz die anderen Alternativen, vielleicht gibt es dort etwas Einfacheres.

• Das lokale Git-Protokoll kann in Kombination mit sshfs verwendet werden, mehrere Benutzer sind möglich, aber im Grunde ist es das gleiche wie im vorherigen Fall.
• http — nur zum Lesen
• git — nur zum Lesen
• https — schwer zu installieren, benötigt zusätzliche Software, irgendetwas. Steuerungspanel Zur Organisation des Zugriffs für Benutzer… scheint umsetzbar, aber irgendwie ist alles kompliziert.

Verwendung des SSH-Protokolls zur Organisation des Mehrbenutzerzugriffs auf den Git-Server.

Kehren wir zum SSH-Protokoll zurück.

Da der Zugriff über SSH für Git verwendet wird, muss die Sicherheit der Serverdaten gewährleistet sein. Der Benutzer, der sich über SSH verbindet, verwendet seinen eigenen Login auf Server Linux, daher kann er sich über einen SSH-Client verbinden und auf die Befehlszeile des Servers zugreifen.
Vollständigen Schutz vor einem solchen Zugriff gibt es nicht.

Aber für den Benutzer sollten die Linux-Dateien nicht von Interesse sein. Wichtige Informationen werden nur im Git-Repository gespeichert. Daher ist es möglich, den Zugriff über die Befehlszeile nicht zu beschränken, sondern durch Linux-Mittel zu verbieten, dass der Benutzer Projekte sieht, außer denen, an denen er beteiligt ist.
Es ist offensichtlich, dass das Linux-Rechtssystem verwendet werden muss.

Wie bereits erwähnt, kann nur ein Konto für den SSH-Zugang verwendet werden. Diese Konfiguration ist für mehrere Benutzer unsicher, obwohl diese Methode in der Liste der empfohlenen Git-Optionen enthalten ist.

Um die zu Beginn des Artikels genannten Anforderungen umzusetzen, wird die folgende Verzeichnisstruktur mit der Zuweisung von Rechten und Eigentümern erstellt:

1) Projektverzeichnisse

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
…
wo
dir1, dir2, dir3 — Projektverzeichnisse: Projekt 1, Projekt 2, Projekt 3.

proj1:proj1, proj2:proj2, proj3:proj3 — speziell erstellte Linux-Benutzer, die als Eigentümer der entsprechenden Projektverzeichnisse zugewiesen werden.

Die Rechte auf alle Verzeichnisse werden auf 0770 festgelegt — voller Zugriff für den Eigentümer und seine Gruppe und vollständiges Verbot für alle anderen.

2) Entwicklerkonten

Entwickler 1: dev1:dev1,proj1,proj2
Entwickler 2: dev2:dev2,proj2,proj3

Der Schlüsselpunkt ist, dass den Entwicklern eine zusätzliche Gruppe des Systembenutzers, der Eigentümer des entsprechenden Projekts ist, zugewiesen wird. Dies geschieht vom Administrator des Linux-Servers mit einem Befehl.

In diesem Beispiel arbeitet „Entwickler 1“ an den Projekten proj1 und proj2, während „Entwickler 2“ an den Projekten proj2 und proj3 arbeitet.

Wenn einer der Entwickler über die Kommandozeile per SSH verbindet, hat er nicht genug Rechte, um auch nur den Inhalt der Projektverzeichnisse zu sehen, an denen er nicht beteiligt ist. Er kann dies selbst nicht ändern.

Da dieses Prinzip auf der grundlegenden Sicherheit der Linux-Rechte basiert, ist dieses Schema zuverlässig. Darüber hinaus ist das Schema sehr einfach zu verwalten.

Kommen wir zur Praxis.

Erstellung von Git-Repositories auf einem Linux-Server

Wir überprüfen.

[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

es ist lästig, alles manuell einzugeben...

[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

Wir stellen sicher, dass es unmöglich ist, über die Kommandozeile auf fremde Repositories zuzugreifen und sogar deren Inhalt zu sehen.

[dev1@server ~]$ cd /var/gitservertest/proj3
-bash: cd: /var/gitservertest/proj3: Berechtigung verweigert
[dev1@server ~]$ ls /var/gitservertest/proj3
ls: kann das Verzeichnis /var/gitservertest/proj3 nicht öffnen: Berechtigung verweigert

Gemeinsames Arbeiten mehrerer Entwickler an einem Git-Projekt

Es bleibt eine Frage: Wenn ein Entwickler eine neue Datei hinzufügt, können die anderen Entwickler diese nicht ändern, da er selbst der Eigentümer ist (zum Beispiel dev1) und nicht der benutzerdefinierte Eigentümer des Projekts (zum Beispiel proj1). Da wir ein Server-Repository haben, muss man zuerst wissen, wie das Verzeichnis „.git“ aufgebaut ist und ob neue Dateien erstellt werden.

Erstellung eines lokalen Git-Repositories und Push auf den Git-Server

Lassen Sie uns zur Clientsituation wechseln.

Microsoft Windows [Version 6.1.7601]
(c) Microsoft Corp., 2009. Alle Rechte vorbehalten.

C:gittest>git init .
Leeres Git-Repository in C:/gittest/.git/ initialisiert.

C:gittest>echo "test dev1 to proj2" > test1.txt

C:gittest>git add .

C:gittest>git status
Auf Branch master
Keine Commits bisher
Änderungen, die committet werden sollen:
  (benutze "git rm --cached ..." um zurückzunehmen)
        neue Datei:   test1.txt

C:gittest>git commit -am "neue Testdatei hinzugefügt"
[master (root-commit) a7ac614] neue Testdatei hinzugefügt
 1 Datei geändert, 1 Einfügung(+)
 Erstellungsmodus 100644 test1.txt
 
C:gittest>git remote add origin "ssh://dev1@10.1.1.11/var/gitservertest/proj2"

C:gittest>git push origin master
dev1:dev1@10.1.1.11's Passwort:
Zähle Objekte: 3, erledigt.
Objekte schreiben: 100% (3/3), 243 Bytes | 243.00 KiB/s, erledigt.
Insgesamt 3 (Delta 0), wiederverwendet 0 (Delta 0)
Zu ssh://10.1.1.11/var/gitservertest/proj2
 * [neuer Branch]      master -> master

C:gittest>

Zur gleichen Zeit entstehen auf dem Server neue Dateien, und sie gehören dem Benutzer, der das Push durchführt.

[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 Verzeichnisse, 18 Dateien
[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]$

Beim Hochladen von Änderungen auf den Server erstellt Git zusätzliche Dateien und Verzeichnisse. Dabei ist ihr Eigentümer tatsächlich der Benutzer, der das Hochladen vornimmt. Aber dann entspricht auch die Gruppe dieser Dateien und Verzeichnisse der primären Gruppe dieses Benutzers, das heißt, die Gruppe dev1 für den Benutzer dev1 und die Gruppe dev2 für den Benutzer dev2 (eine Änderung der primären Gruppe des Entwicklers wird nicht helfen, da er dann nicht an mehreren Projekten arbeiten kann). In diesem Fall kann der Benutzer dev2 die von Benutzer dev1 erstellten Dateien nicht ändern, was die Funktionalität beeinträchtigen könnte.

Linux chown — Der Eigentümer einer Datei wird durch einen normalen Benutzer geändert.

Der Eigentümer der Datei kann deren Zugehörigkeit nicht ändern. Er kann jedoch die Gruppe der Datei, die ihm gehört, ändern, sodass diese Datei von anderen Benutzern, die sich in derselben Gruppe befinden, geändert werden kann. Das ist es, was wir brauchen.

Verwendung von Git Hook

Das Arbeitsverzeichnis für das hook ist das Wurzelverzeichnis des Projekts. Das hook ist eine ausführbare Datei, die unter dem Benutzer läuft, der den Push durchführt. Wissen wir das, können wir das Vorhaben umsetzen.

[dev1@server proj2]$ mv hooks/post-update{.sample,}
[dev1@server proj2]$ sed -i '2,$ s/^/#/' hooks/post-update
[dev1@server proj2]$ cat <<> hooks/post-update

oder einfach

vi hooks/post-update

Kehren wir zum Client zurück.

C:gittest>echo "dev1 3. Zeile" >> test1.txt

C:gittest>git commit -am "3. von dev1, Server-Hook testen"
[master b045e22] 3. von dev1, Server-Hook testen
 1 Datei geändert, 1 Einfügung(+)

C:gittest>git push origin master
dev1:dev1@10.1.1.11's Passwort:
   d22c66e..b045e22 master -> master

Auf dem Git-Server überprüfen wir nach dem Commit die Funktionsweise des post-update-Hook-Skripts.

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

— leer, alles in Ordnung.

Anschluss eines zweiten Entwicklers in Git

Lassen Sie uns die Arbeit des zweiten Entwicklers simulieren.

Auf dem Client

C:gittest>git remote remove origin

C:gittest>git remote add origin "ssh://dev2@10.1.1.11/var/gitservertest/proj2"

C:gittest>echo "!!! dev2 hat das hinzugefügt" >> test1.txt

C:gittest>echo "!!! dev2 schrieb" > test2.txt

C:gittest>git add test2.txt

C:gittest>git commit -am "dev2 hat test1 hinzugefügt und test2 erstellt"
[master 55d49a6] dev2 hat test1 hinzugefügt und test2 erstellt
 2 Dateien geändert, 2 Einfügungen(+)
 Erstellungsmodus 100644 test2.txt

C:gittest>git push origin master
dev2@10.1.1.11's Passwort:
   b045e22..55d49a6 master -> master

Und gleichzeitig, auf dem Server…

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

— wieder leer, alles funktioniert.

Löschen des Git-Projekts und Herunterladen des Projekts vom Git-Server

Nun kann man noch einmal überprüfen, ob alle Änderungen gespeichert wurden.

C:gittest>rd /S /Q .
Der Prozess kann nicht auf die Datei zugreifen, da diese Datei von einem anderen Prozess verwendet wird.

— um das Git-Projekt zu löschen, löschen wir einfach das Verzeichnis vollständig. Lassen Sie uns mit der angezeigten Fehlermeldung umgehen, da das aktuelle Verzeichnis mit diesem Befehl nicht gelöscht werden kann, aber genau diese Verhaltensweise benötigen wir.

C:gittest>dir
 Inhalt des Ordners C:gittest

21.06.2019  08:43              .
21.06.2019  08:43              ..

C:gittest>git clone ssh://dev2@10.1.1.11/var/gitservertest/proj2
In 'proj2' klonen...
dev2@10.1.1.11's Passwort:

C:gittest>cd proj2

C:gittestproj2>dir
 Inhalt des Ordners C:gittestproj2

21.06.2019  08:46              .
21.06.2019  08:46              ..
21.06.2019  08:46               114 test1.txt
21.06.2019  08:46                19 test2.txt
C:gittestproj2>type test1.txt
"test dev1 zu proj2"
"dev1 hat etwas anderes hinzugefügt"
"dev1 3. Zeile"
"!!! dev2 hat das hinzugefügt"

C:gittestproj2>type test2.txt
"!!! dev2 schrieb"

Zugriffsaufteilung in Git

Jetzt stellen wir sicher, dass auch über Git der zweite Entwickler keinen Zugriff auf das Projekt Proj1 hat, an dem er nicht arbeitet.

C:gittestproj2>git remote remove origin

C:gittestproj2>git remote add origin "ssh://dev2@10.1.1.11/var/gitservertest/proj1"

C:gittestproj2>git push origin master
dev2@10.1.1.11's Passwort:
fatal: '/var/gitservertest/proj1' scheint kein Git-Repository zu sein
fatal: Vom Remote-Repository konnte nicht gelesen werden.

Bitte stellen Sie sicher, dass Sie die richtigen Zugriffsrechte haben
und das Repository existiert.

Jetzt den Zugriff erlauben

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

und danach funktioniert alles.

C:gittestproj2>git push origin master
dev2@10.1.1.11's Passwort:
Zum ssh://10.1.1.11/var/gitservertest/proj1
 * [neuer Branch]      master -> master

Zusätzliche Informationen

Zusätzlich, wenn es Probleme mit den Standardrechten beim Erstellen von Dateien und Verzeichnissen gibt, kann man in CentOS den Befehl verwenden

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

Auch in dem Artikel können Sie auf nützliche Kleinigkeiten stoßen:

• wie man in Linux ein Verzeichnisbaum aufbaut
• wie man in sed einen Adressbereich von einer bestimmten Zeile bis zum Ende der Datei übergibt, also eine Ersetzung in sed in allen Zeilen außer der ersten Zeile vornimmt
• Wie man in Linux find die Suchbedingung invertiert
• wie man in der Linux-Shell mehrere Zeilen über eine Einzeiler in eine Schleife übergibt
• wie man in bash einfache Anführungszeichen maskiert
• wie man in der Windows-Eingabeaufforderung ein Verzeichnis zusammen mit allen Inhalten löscht
• Wie man mit bash mv eine Datei umbenennt, ohne sie neu zu schreiben

Danke für Ihre Aufmerksamkeit.

Quelle: habr.com