Organisation des Mehrbenutzerzugriffs auf den GIT-Server

Bei der Installation und Konfiguration eines Git-Servers stellt sich die Frage, ob der Zugriff mehrerer Benutzer auf mehrere Projekte organisiert werden soll. Ich habe das Problem untersucht und eine Lösung gefunden, die alle meine Anforderungen erfĂŒllt: einfach, sicher, zuverlĂ€ssig.

Meine WĂŒnsche sind wie folgt:

  • Jeder Benutzer verbindet sich mit seinem eigenen Konto
  • Mehrere Benutzer können an einem Projekt arbeiten
  • Der gleiche Benutzer kann an mehreren Projekten arbeiten
  • Jeder Benutzer hat nur Zugriff auf die Projekte, an denen er arbeitet
  • sollte in der Lage sein, eine Verbindung ĂŒber die Befehlszeile und nicht nur ĂŒber eine Art Webschnittstelle herzustellen

Es wÀre auch toll:

  • GewĂ€hren Sie Kontrollpersonen schreibgeschĂŒtzte Rechte
  • Benutzerberechtigungen in Git bequem verwalten

Übersicht der Optionen fĂŒr den Zugriff auf den GIT-Server


ZunĂ€chst mĂŒssen Sie wissen, aus was Sie auswĂ€hlen können, um einen kurzen Überblick ĂŒber die Git-Protokolle zu erhalten.

  • ssh - Ein speziell erstelltes Benutzerkonto wird verwendet, um auf den Server zuzugreifen.
    • Es ist seltsam, dass Git die Verwendung eines einzelnen Kontos fĂŒr den Zugriff auf alle Repositorys nicht von den Empfehlungen ausschließt. Dies entspricht nicht meinen Anforderungen.
    • Sie können mehrere Konten verwenden, aber wie kann der Benutzerzugriff nur auf bestimmte Verzeichnisse beschrĂ€nkt werden?

      • Das Schließen zum Home-Verzeichnis ist nicht geeignet, da es schwierig ist, dort den Schreibzugriff fĂŒr andere Benutzer zu organisieren
      • Die Verwendung symbolischer Links aus Ihrem Home-Verzeichnis ist ebenfalls schwierig, da Git sie nicht als Links interpretiert
      • Es ist möglich, den Zugriff auf den Dolmetscher einzuschrĂ€nken, es gibt jedoch keine vollstĂ€ndige Garantie dafĂŒr, dass dies immer funktioniert

        • Sie können sogar Ihren eigenen Befehlsinterpreter fĂŒr solche Benutzer anschließen, aber,

          • Erstens ist dies bereits eine schwierige Entscheidung.
          • und in 2 kann dies umgangen werden.

    Aber vielleicht ist dies kein Problem, dass der Benutzer Befehle ausfĂŒhren kann? .. Im Allgemeinen kann diese Methode nicht ausgeschlossen werden, wenn Sie wissen, wie sie verwendet wird. Wir werden spĂ€ter auf diese Methode zurĂŒckkommen, aber jetzt kurz die anderen Alternativen betrachten, vielleicht wird dort etwas einfacher.
  • Das lokale Git-Protokoll kann in Kombination mit sshfs verwendet werden, es können mehrere Benutzer verwendet werden, dies ist jedoch im Wesentlichen dasselbe wie im vorherigen Fall
  • http - schreibgeschĂŒtzt
  • Git ist schreibgeschĂŒtzt
  • https - Die Installation ist schwierig. Sie benötigen zusĂ€tzliche Software und eine Art Bedienfeld fĂŒr die Organisation des Benutzerzugriffs. Es sieht machbar aus, ist aber irgendwie kompliziert.

Verwenden des SSH-Protokolls zum Organisieren des Mehrbenutzerzugriffs auf den Git-Server


ZurĂŒck zum SSH-Protokoll.

Da der SSH-Zugriff fĂŒr Git verwendet wird, mĂŒssen Sie die Serverdaten sichern. Der Benutzer, der ĂŒber ssh eine Verbindung herstellt, verwendet sein eigenes Login auf dem Linux-Server, sodass er ĂŒber den ssh-Client eine Verbindung herstellen und Zugriff auf die Serverbefehlszeile erhalten kann.
Es gibt keinen vollstÀndigen Schutz gegen einen solchen Zugang.

Der Benutzer sollte sich jedoch nicht fĂŒr Linux-Dateien interessieren. Wichtige Informationen werden nur im Git-Repository gespeichert. Daher können Sie den Zugriff ĂŒber die Befehlszeile nicht einschrĂ€nken, aber Linux kann den Benutzer daran hindern, Projekte anzusehen, mit Ausnahme derjenigen, an denen er teilnimmt.
Offensichtlich mit dem Linux-Berechtigungssystem.

Wie bereits erwĂ€hnt, ist es möglich, nur ein Konto fĂŒr den SSH-Zugriff zu verwenden. Diese Konfiguration ist fĂŒr mehrere Benutzer nicht sicher, obwohl diese Methode in der Liste der empfohlenen Git-Optionen enthalten ist.

Um die am Anfang des Artikels angegebenen 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 Direktoren der jeweiligen Projektverzeichnisse ernannt werden.

Die Rechte an allen Verzeichnissen sind in 0770 festgelegt - vollstĂ€ndiger Zugriff fĂŒr den EigentĂŒmer und seine Gruppe und ein vollstĂ€ndiges Verbot fĂŒr alle anderen.

2) Entwicklerkonten

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

Der entscheidende Punkt ist, dass Entwicklern eine zusĂ€tzliche Gruppe des Systembenutzers zugewiesen wird, dem das entsprechende Projekt gehört. Dies wird vom Linux-Serveradministrator als einzelner Befehl ausgefĂŒhrt.

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

Wenn einer der Entwickler ĂŒber ssh ĂŒber die Befehlszeile eine Verbindung herstellt, reichen seine Rechte nicht einmal aus, um den Inhalt von Projektverzeichnissen anzuzeigen, an denen er nicht beteiligt ist. Er selbst kann dies in keiner Weise Ă€ndern.

Da die Grundlage dieses Prinzips die grundlegende Sicherheit von Linux-Rechten ist, ist dieses Schema zuverlĂ€ssig. DarĂŒber hinaus ist das Schema sehr einfach zu verwalten.

Lass uns weiter ĂŒben.

Erstellen von Git-Repositorys auf einem Linux-Server


Wir prĂŒ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 

mĂŒde vom Tippen mit meinen HĂ€nden ...

 [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 Befehlszeile auf die Repositorys anderer Personen zuzugreifen und deren Inhalt anzuzeigen.

 [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 

Zusammenarbeit mehrerer Entwickler in Git an einem Projekt


Eine Frage bleibt, wenn ein Entwickler eine neue Datei einfĂŒhrt, kann der Rest der Entwickler sie nicht Ă€ndern, da er sie selbst besitzt (z. B. dev1) und nicht der Benutzer, dem das Projekt gehört (z. B. proj1). Da wir ein Server-Repository haben, mĂŒssen Sie zunĂ€chst wissen, wie das Verzeichnis ".git" angeordnet ist und ob neue Dateien erstellt werden.

Erstellen eines lokalen Git-Repositorys und Push auf einen Git-Server


Fahren wir mit dem Client-Computer fort.

 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://dev1@10.1.1.11/var/gitservertest/proj2" C:\gittest>git push origin master dev1:dev1@10.1.1.11'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> 

Gleichzeitig werden auf dem Server neue Dateien erstellt, die dem Benutzer gehören, der den Push ausgefĂŒhrt hat

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

Wenn die Änderungen auf den Git-Server hochgeladen werden, werden zusĂ€tzliche Dateien und Verzeichnisse erstellt, und gleichzeitig ist der Benutzer, der den Upload durchfĂŒhrt, der EigentĂŒmer. Die Gruppe dieser Dateien und Verzeichnisse entspricht dann aber auch der Hauptgruppe dieses Benutzers, dh der Gruppe dev1 fĂŒr den Benutzer dev1 und der Gruppe dev2 fĂŒr den Benutzer dev2 (das Ändern der Hauptgruppe des Entwicklungsbenutzers hilft seitdem nicht mehr, wie man an mehreren Projekten arbeitet?). In diesem Fall kann der Benutzer dev2 die vom Benutzer dev1 erstellten Dateien nicht Ă€ndern, was zu einer Verletzung der FunktionalitĂ€t fĂŒhrt.

Linux chown - Ändern des Besitzers einer Datei durch einen normalen Benutzer



Der EigentĂŒmer der Datei kann seinen EigentĂŒmer nicht Ă€ndern. Er kann jedoch die Gruppe der Datei Ă€ndern, die ihm gehört, und diese Datei kann dann fĂŒr andere Benutzer in derselben Gruppe geĂ€ndert werden. Das brauchen wir.

Git Hook verwenden


Das Arbeitsverzeichnis fĂŒr den Hook ist das Stammverzeichnis des Projekts. hook ist eine ausfĂŒhrbare Datei, die unter dem Benutzer ausgefĂŒhrt wird, der Push ausfĂŒhrt. Wenn wir das wissen, können wir unseren Plan erfĂŒllen.

 [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 

entweder nur

 vi hooks/post-update 

ZurĂŒck zum Client-Computer.

 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:dev1@10.1.1.11's password: d22c66e..b045e22 master -> master 

Auf dem Git-Server ĂŒberprĂŒfen wir nach dem Festschreiben die Funktion des Hook-Post-Update-Skripts

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

- leer, alles ist gut

Einen zweiten Entwickler mit Git verbinden


Wir werden die Arbeit des zweiten Entwicklers nachahmen.

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 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 dev2@10.1.1.11's password: b045e22..55d49a6 master -> master 

Und gleichzeitig auf dem Server ...

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

- wieder leer, alles funktioniert.

Entfernen eines Git-Projekts und Herunterladen eines Projekts von einem Git-Server


Nun, Sie können erneut sicherstellen, dass alle Änderungen erhalten bleiben.

 C:\gittest>rd /S /Q .       ,       . 

- Um ein Git-Projekt zu entfernen, löschen Sie einfach das Verzeichnis vollstĂ€ndig. Wir werden den generierten Fehler ertragen, da es unmöglich ist, das aktuelle Verzeichnis fĂŒr diesen Befehl zu löschen, aber wir brauchen nur dieses Verhalten.

 C:\gittest>dir   C:\gittest 21.06.2019 08:43 <DIR> . 21.06.2019 08:43 <DIR> .. C:\gittest>git clone ssh://dev2@10.1.1.11/var/gitservertest/proj2 Cloning into 'proj2'... dev2@10.1.1.11's password: C:\gittest>cd proj2 C:\gittest\proj2>dir   C:\gittest\proj2 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:\gittest\proj2>type test1.txt "test dev1 to proj2" "dev1 added some omre" "dev1 3rd line" "!!! dev2 added this" C:\gittest\proj2>type test2.txt "!!! dev2 wrote" 

Freigabe des Zugriffs in Git


Stellen wir nun sicher, dass der zweite Entwickler selbst ĂŒber Git keinen Zugriff auf das Proj1-Projekt erhĂ€lt, an dem er nicht arbeitet.

 C:\gittest\proj2>git remote remove origin C:\gittest\proj2>git remote add origin "ssh://dev2@10.1.1.11/var/gitservertest/proj1" C:\gittest\proj2>git push origin master dev2@10.1.1.11'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. 

Erlauben Sie nun den Zugriff

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

und danach funktioniert alles.

 C:\gittest\proj2>git push origin master dev2@10.1.1.11's password: To ssh://10.1.1.11/var/gitservertest/proj1 * [new branch] master -> master 

ZusÀtzliche Informationen


Wenn beim Erstellen von Dateien und Verzeichnissen ein Problem mit den Standardberechtigungen auftritt, können Sie den Befehl in CentOS verwenden

 setfacl -Rd -mo::5 -mg::7 /var/gitservertest 

Auch im Artikel können Sie auf kleine nĂŒtzliche Dinge stoßen:

  • Wie erstelle ich einen Verzeichnisbaum unter Linux?
  • wie man sed macht, um einen Adressbereich von einer bestimmten Zeile an das Ende der Datei zu ĂŒbertragen, dh um in sed in allen Zeilen außer der ersten Zeile einen Ersatz vorzunehmen
  • Wie unter Linux finden, um einen Suchbegriff umzukehren
  • Wie man in einer Linux-Shell mehrere Zeilen durch eine einzelne Zeile schleift
  • wie man einfachen AnfĂŒhrungszeichen in Bash entgeht
  • So löschen Sie das Verzeichnis mit allen Inhalten in der Windows-Befehlszeile
  • So verwenden Sie bash mv, um eine Datei umzubenennen, ohne sie erneut zu schreiben

Vielen Dank fĂŒr Ihre Aufmerksamkeit.

Source: https://habr.com/ru/post/de457056/


All Articles