Du bist nicht angemeldet.

#1 09.06.2020 11:38:57

Nilse
Mitglied

Apache2 und User http

Hallo Zusammen,
ich habe einen Apache2 mit PHP mit Hilfe des Wikis erfolgreich zum laufen gebracht. Jetzt habe ich angefangen ein paar Projekte auf dem System laufen zu lassen. Ich mache alle Befehle in dem /srv/http Ordner als der User "http":

 sudo -u http vim index.php 

Der Ordner gehört auch "http" und auch der Gruppe "http". Jetzt habe ich das Problem, dass der User "http" keinen Zugriff auf Swap files hat. Vim, z.B. erstellt immer eine swp Datei beim öffnen.
Wenn ich ein Projekt via github dorthin auschecke, und dann bspw.

 sudo -u http git config credential.helper store 

mache, kann der User http nicht in die Konfigurationsdatei von Git schreiben. Diese Daten (auch die vim Daten) kommen ja ins User-Verzeichnis. Dieser User hat keins, weil es ja nur für den Apache Dienst zuständig ist. Ausserdem will ich nicht, dass der Benutzer per ssh angemeldet werden kann.

Wie ist das die korrekte Vorgehensweise? Oder sollte ich das immer als mein User bearbeiten, und dann am Ende ein

 sudo chown http:http 

machen? Mein Benutzer ist auch in der Gruppe http, allerdings ändert das nicht, da die Dateien dann trotzdem von meinem User bearbeitet wurden, und nicht von http, und der Apache, bzw. php kann die Datei dann nicht mehr ausführen.

Würde mich freuen, wenn Ihr mir da helfen könntet.

Grüße
Nilse

Offline

#2 09.06.2020 13:19:38

schard
Moderator

Re: Apache2 und User http

Der Benutzer http ist dazu da, einen eingeschränkten Benutzerkontext für den Webserver und ggf. PHP Interpreter zur Verfügung zu stellen.
Es ist nicht Sinn und Zweck, diesen zur Administration der Website-Dokumente und PHP-Dateien zu verwenden.
Hierfür ist das root-Konto weitaus besser geeignet, da es per Definition für die Administration des Systems vorgesehen ist.
Der Ordner /srv/http und etwaige Unterordner sollten auch niemals dem Benutzer gehören, in dessen Kontext der PHP Interpreter läuft.
Dies ermöglicht nämlich die einfache Manipulation etwaiger PHP Dokumente im Falle einer PHP-seitigen Sicherheitslücke und das Einschleusen von Backdoors.
Du unterminierst mit deinem aktuellen Vorgehen die Sicherheit deines Webservers.
Dateien, welche vom Webserver oder PHP Interpreter geserved werden sollen, müssen von dessen Benutzer lediglich gelesen werden können.
Weitere Rechte bergen nur Schadenspotential.

Offline

#3 09.06.2020 13:33:13

Gerry_Ghetto
Mitglied

Re: Apache2 und User http

Meiner Erfahrung nach werden die Dateien der Webseite nie direkt bearbeitet. Üblicherweise läuft irgendwo ein Webserver mit den Dateien der Webseite in einer gewissen Version. Der Code/die Dateien für die Webseite werden dann separat in einem Git-Repo bearbeitet und mittels CI/CD (Jenkins zum Beispiel) auf den Webserver geschoben (idealerweise wird nur das deployed, was auch wirklich nötig ist).

Deine Beschreibung tönt allerdings eher danach, dass du eigentlich nur Entwickeln musst/willst und den Webserver nur am Laufen hast, damit die Webseite bei dir lokal getestet werden kann. In einem solchen Fall würde ich den Webserver/Datenbank/PHP in Container packen (Docker zum Beispiel). Die Webseite ist dann lokal bei dir im Benutzerverzeichnis und kann von dir problemlos bearbeitet werden. Wenn die Container laufen, kannst du die Webseite über localhost aufrufen.

Ich bin kein Webentwickler, aber eigentlich sollte eine IDE auch in der Lage sein, einen lokalen Webserver zu starten, um den Code zu testen, so dass du dein kompliziertes Setup gar nicht brauchst, respektive sauber zwischen Entwicklung und Produktion trennen kannst.

Anpassungen der Gruppen und Berechtigungen reissen oft Sicherheitslücken auf, die einem nicht so richtig bewusst sind, insbesondere in Kombination mit schlechter Konfiguration.

Und falls du den .git Ordner über den Browser aufrufen kannst, dann hast du jetzt auch schon ein Problem.

Deine Frage ist übrigens so gestellt, dass du von n Personen n + k Meinungen bekommst, wobei n und k Elemente der natürlichen Zahlen sind.

Offline

#4 09.06.2020 13:42:27

schard
Moderator

Re: Apache2 und User http

Gerry_Ghetto schrieb:

Meiner Erfahrung nach werden die Dateien der Webseite nie direkt bearbeitet.

Du, ich habe schon Pferde kotzen sehen.

Gerry_Ghetto schrieb:

Üblicherweise läuft irgendwo ein Webserver mit den Dateien der Webseite in einer gewissen Version. Der Code/die Dateien für die Webseite werden dann separat in einem Git-Repo bearbeitet und mittels CI/CD (Jenkins zum Beispiel) auf den Webserver geschoben (idealerweise wird nur das deployed, was auch wirklich nötig ist).

Ich nutze zwar Git über SSH, aber prinzipiell ist dies ein sinnvolles Vorgehen, ja.

Gerry_Ghetto schrieb:

Deine Beschreibung tönt allerdings eher danach, dass du eigentlich nur Entwickeln musst/willst und den Webserver nur am Laufen hast, damit die Webseite bei dir lokal getestet werden kann. In einem solchen Fall würde ich den Webserver/Datenbank/PHP in Container packen (Docker zum Beispiel). Die Webseite ist dann lokal bei dir im Benutzerverzeichnis und kann von dir problemlos bearbeitet werden. Wenn die Container laufen, kannst du die Webseite über localhost aufrufen.

Wenn es sich um eine lokale Workstation in einem gesicherten Development-Netzwerk handelt, würde ich sogar von Virtualisierung absehen - alleine wegen des Konfigurationsaufwands.
Allerdings ist auch dies eine der saubersten Lösungen.

Gerry_Ghetto schrieb:

Ich bin kein Webentwickler, aber eigentlich sollte eine IDE auch in der Lage sein, einen lokalen Webserver zu starten, um den Code zu testen, so dass du dein kompliziertes Setup gar nicht brauchst, respektive sauber zwischen Entwicklung und Produktion trennen kannst.

Bevor meine IDE so einen Murks anbietet, sollte sie eher die Möglichkeit besitzen Kaffee zu kochen.
Im Ernst. Deployment und Testing sind nicht Aufgabe einer IDE.

Gerry_Ghetto schrieb:

Anpassungen der Gruppen und Berechtigungen reissen oft Sicherheitslücken auf, die einem nicht so richtig bewusst sind, insbesondere in Kombination mit schlechter Konfiguration.

Das ist nur der Fall, wenn man nicht weiß, was man tut.
In diesem Fall sollte man allerdings von vornherein keine Webanwendungen hosten.
Die korrekte Anpassung von Benutzer- und Gruppenrechten ist Aufgabe eines jeden Systemadministrators.

Gerry_Ghetto schrieb:

Und falls du den .git Ordner über den Browser aufrufen kannst, dann hast du jetzt auch schon ein Problem.

Nur, wenn man diesen nicht hosten wollte.
Da wir in unserer Firma Rolling Release betrieben, checken wir auch Git-Repos direkt ins Webroot aus.
Dies erleichtert in unserem Fall das kontinuierliche Deployment.
Die .git* Dateien und Ordner haben wir allerdings per Webserver-Konfiguration gesperrt.
Alles kein Thema, wenn man weiß, was man da tut.

Das eigentliche Problem beim ungewollten Hosten von Git-Repos ist ja nicht das man an den Quelltext kommt, was ja zumindest bei Backend-Programmen nicht unbedingt gewollt ist, sondern dass einige 1D1073N Credentials (Benutzername / Passwort / private Schlüssel) in den Quelltext hardcoden, welche dann von jedermann abrufbar sind.
Wer Code und Konfiguration sauber trennt, läuft allerdings erst gar nicht in dieses Problem.

Gerry_Ghetto schrieb:

Deine Frage ist übrigens so gestellt, dass du von n Personen n + k Meinungen bekommst, wobei n und k Elemente der natürlichen Zahlen sind.

Jo. Das ist wie mit "Fragste zwei Anwälte, kriegste drei Meinungen.".

Offline

#5 09.06.2020 19:16:19

Gerry_Ghetto
Mitglied

Re: Apache2 und User http

schard schrieb:
Gerry_Ghetto schrieb:

Deine Beschreibung tönt allerdings eher danach, dass du eigentlich nur Entwickeln musst/willst und den Webserver nur am Laufen hast, damit die Webseite bei dir lokal getestet werden kann. In einem solchen Fall würde ich den Webserver/Datenbank/PHP in Container packen (Docker zum Beispiel). Die Webseite ist dann lokal bei dir im Benutzerverzeichnis und kann von dir problemlos bearbeitet werden. Wenn die Container laufen, kannst du die Webseite über localhost aufrufen.

Wenn es sich um eine lokale Workstation in einem gesicherten Development-Netzwerk handelt, würde ich sogar von Virtualisierung absehen - alleine wegen des Konfigurationsaufwands.
Allerdings ist auch dies eine der saubersten Lösungen.

Ein weiterer Vorteil von Containern ist, dass du einfacher verschiedene Versionen testen kannst. Wenn deine Webseite mit PHP in Version X läuft, dann kannst du auch mal testen, wie sie sich mit Version Y verhält, indem du den Container anpasst.

Ein Nachteil von Containern ist, dass du dich darauf verlassen musst, dass sie sicher konfiguriert sind oder du musst dich selber einarbeiten, um zu verstehen, was in den Containern abgeht. Aber wenn du einen sicher vorkonfigurierten Container nimmst, dann sparst du dir den Konfigurationsaufwand.

schard schrieb:
Gerry_Ghetto schrieb:

Ich bin kein Webentwickler, aber eigentlich sollte eine IDE auch in der Lage sein, einen lokalen Webserver zu starten, um den Code zu testen, so dass du dein kompliziertes Setup gar nicht brauchst, respektive sauber zwischen Entwicklung und Produktion trennen kannst.

Bevor meine IDE so einen Murks anbietet, sollte sie eher die Möglichkeit besitzen Kaffee zu kochen.
Im Ernst. Deployment und Testing sind nicht Aufgabe einer IDE.

Ich finde diese Möglichkeit eigentlich ziemlich praktisch. Ich kenne es hauptsächlich von Eclipse, das lokal Tomcat starten kann. Dann kann ich die Webapplikation im Browser aufrufen und gleichzeitig im Javacode debuggen.
Auch Django bringt einen eigenen Webserver mit, den man starten kann. Ich vermute, im PHP Umfeld gibt es das auch.

Aber da es von mir missverständlich formuliert wurde: Selbstverständlich sollte ein so gestarteter Webserver niemals als (Produktiv-) Server von aussen (Internet, je nach dem auch nicht aus dem Intranet) erreichbar sein! Und auf deiner Entwicklermaschine sollte unter keinen Umständen ein produktiver Webserver laufen. Entwicklung und Produktion müssen physisch und netzwerktechnisch voneinander getrennt sein.

schard schrieb:
Gerry_Ghetto schrieb:

Anpassungen der Gruppen und Berechtigungen reissen oft Sicherheitslücken auf, die einem nicht so richtig bewusst sind, insbesondere in Kombination mit schlechter Konfiguration.

Das ist nur der Fall, wenn man nicht weiß, was man tut.
In diesem Fall sollte man allerdings von vornherein keine Webanwendungen hosten.
Die korrekte Anpassung von Benutzer- und Gruppenrechten ist Aufgabe eines jeden Systemadministrators.

Und woher soll man wissen, ob man wirklich weiss, was man tut? Oftmals sind es ja ausgerechnet die Profis, die am unsichersten arbeiten, weil sie "ja schliesslich genau wissen", was sie tun und sie das "früher auch immer so gemacht" haben und "noch nie etwas passiert" ist.

Und wenn du Nutzer X zur Gruppe Y hinzufügst: Auch Firefox läuft mit den Rechten von Benutzer X. Heisst aber nicht, dass Firefox die Dinge nur mit Wissen und Willen des menschlichen Benutzers tut.

schard schrieb:
Gerry_Ghetto schrieb:

Und falls du den .git Ordner über den Browser aufrufen kannst, dann hast du jetzt auch schon ein Problem.

Nur, wenn man diesen nicht hosten wollte.
Da wir in unserer Firma Rolling Release betrieben, checken wir auch Git-Repos direkt ins Webroot aus.
Dies erleichtert in unserem Fall das kontinuierliche Deployment.
Die .git* Dateien und Ordner haben wir allerdings per Webserver-Konfiguration gesperrt.
Alles kein Thema, wenn man weiß, was man da tut.

Das eigentliche Problem beim ungewollten Hosten von Git-Repos ist ja nicht das man an den Quelltext kommt, was ja zumindest bei Backend-Programmen nicht unbedingt gewollt ist, sondern dass einige 1D1073N Credentials (Benutzername / Passwort / private Schlüssel) in den Quelltext hardcoden, welche dann von jedermann abrufbar sind.
Wer Code und Konfiguration sauber trennt, läuft allerdings erst gar nicht in dieses Problem.

Ich sehe in den allermeisten Fällen keinen Grund, warum man .git im Wurzelverzeichnis vom Webserver haben, geschweige denn hosten wollen würde.
Und in den wenigen Fällen, in denen es vielleicht Sinn macht, müsste und sollte man ein detailliertes Schutzkonzept haben, das auch häufig überprüft wird. Ausser man möchte die Werbewirksamkeit erhöhen, indem das eine oder andere News-Portal früher oder später mal über die Firma berichtet.

In den Fällen, in denen man Git als Deployment-Ersatz nutzen möchte, würde ich empfehlen, dass lediglich ein Unterordner vom Repository als Wurzelverzeichnis des Webservers dient.
Grundsätzlich bin ich der Meinung, dass ins Wurzelverzeichnis des Webservers nur Dateien hingehören, die der Webserver auch tatsächlich braucht.

Auch wenn ich jetzt viel geschrieben habe: Ich bin kein Webentwickler und auch kein Administrator von Webservern. Es kann also gut sein, dass ich etwas falsches geschrieben habe.

Offline

Schnellantwort auf dieses Thema

Schreibe deinen Beitrag und versende ihn
Deine Antwort

Fußzeile des Forums