staging.inyokaproject.org

Apache_2.4/#Rechte

Fehlt hier noch ein

sudo find /var/www/html -type d -exec chmod g+s {} \; 

?

Sonst gehören neu angelegte Dateien in dem Ordner wieder "nur" der Primärgruppe des Users.

Gruß BillMaier

Hallo,

Steev hatte heute dankenswerter Weise den Artikel für Bionic getestet. Aber leider ein bisschen "dünn" drünber, da einige Befehle nicht aus systemd aktualisiert wurden, was nun mal bei Bionic Stand der Dinge ist. Bitte zeitnah nachholen, damit der Artikel komplett auf dem aktuellem Stand ist. Danke!

Gruß, noisefloor

Danke fürs Zurücksetzen. Ist besser so.

Gruß BillMaier

und täglich grüßt das Murmeltier ☹

/edit: wieder zurück gesetzt. Wenn jemand den Überarbeiter anschreiben will, gerne. ich muss gleich weg.

ungetestet wie alle Unterartikel dazu

Hallo,

da der Artikel schon mehrfach als getestet markiert wurde, ohne die Umstellung auf systemd zu berücksichtigen, könnten wir ihn auch als getestet markieren und eine fehlerhaft-Box mit der systemd-Info ergänzen. Das würde den Stand des Artikels präzisieren.

Ansonsten ist das ja nachwievor die Version Apache 2.4 .

Gruß BillMaier

BillMaier schrieb:

Apache_2.4/#Rechte

Fehlt hier noch ein

sudo find /var/www/html -type d -exec chmod g+s {} \; 

?

Sonst gehören neu angelegte Dateien in dem Ordner wieder "nur" der Primärgruppe des Users.

push

Hallo,

hab den Artikel mal überarbeitet, z.B. upstart → systemd. Aus meiner Sicht könnte der Abschnitt "Problembehebung" raus, da dies kein typisches Apache-Problem ist. Auf die Problematik wird ja auch im verlinkten Artikel hingewiesen.

Gruß BillMaier

Ist die Erwähnung von 2.4 im Artikelnamen noch sinnvoll, nachdem der Artikel zu Apache 2.2 vor ein paar Jahren archiviert wurde?

mindestens muss der Artikelname als redirect bestehen bleiben, weil er an ganz verschiedenen Teilen so verlinkt ist. Aber von mir aus können wir das auch so machen

Apache_2.4 → Apache

Gruß BillMaier

Hallo,

wir können es auch so lassen in weisester Voraussicht und Apache → Apache 2.4 weiterleiten. Die Lösung ist zukunftsrobuster, wenn mal Apache 2.6 kommt.

Gruß, noisefloor

mir egal.

Hallo, ich möchte gerne anregen, ob man vielleicht den Bereich "Rechte" nochmal etwas ausführlicher beschreiben könnte, gerade für Leute, die den LAMP-Stack zum Entwickeln benutzen.

Wenn man CMS wie Wordpress installiert, läuft man in der Standardkonfiguration in ein ziemliches Rechtechaos hinein. Befolgt man den Rat, alles in /var/www/html zu legen und mit dem eigenen Account über sudo da reinzuschreiben, haben alle Dateien Eigentümer und Gruppe root und der Webserverprozess darf da nicht reinschreiben, was zu Fehlfunktionen in Wordpress führt. Nimmt man die Dokumente ins eigene Home-Verzeichnis und richtet Virtual Hosts ein, hat man dasselbe Problem, nur dann mit dem eigenen User. Man muss entweder mit chmod alles aufmachen oder ändert den Eigentümer aller Dateien auf www-data und muss jedes Mal, wenn man mit dem eigenen Account etwas schreibt, den Eigentümer ändern. Den eigenen User zur Gruppe www-data hinzuzufügen, löst das Problem leider nicht.

Zum Entwickeln habe ich es jetzt so gemacht, dass ich für den Webserver einen neuen Benutzer namens webmaster angelegt und ihn zunächst keinen weiteren Gruppen zugeordnet habe. In der Apache-Konfiguration unter envvars habe ich diesen Benutzer für den Webserverprozess eingetragen (diese Info ist auf Ubuntuusers nicht vorhanden). Dann habe ich unter /home/webmaster/www meine Daten abgelegt und Virtual Hosts für phpMyAdmin und Wordpress eingerichtet, die dorthin verweisen. Vorteil dieser Konfiguration ist, dass ich durchgängig mit Standardrechten 755/644 arbeiten kann, was die Übertragung auf den endgültigen Webserver erleichtert und ich kann über SSH/SFTP mit dem Editor in diesen Verzeichnissen schreiben, ohne Eigentümerchaos anzurichten. Wenn ich mit Windows darauf zugreifen will, installiere ich Samba und füge den User webmaster einfach noch der Gruppe sambashare hinzu und fertig.

Das Argument, dass der Webserverprozess nicht durchgängig im Webroot schreiben können soll, kann ich schon nachvollziehen, aber wenn ein derartiger Angriff gelänge, wäre nicht nur meine Konfiguration, sondern auch die vieler Hostinganbieter, die ihre Systeme ähnlich einrichten, von dem Problem betroffen. Apache 2.4 ist mittlerweile so gut abgehangen, dass man die Gefahr als sehr gering einschätzen kann und wenn man seine Daten regelmäßig in einen Bereich außerhalb des Webroots sichert, kann man auch nicht viel verlieren.

Hallo,

Danke für das ausführliche Feedback. Grundsätzlich kratzt der Wikiartikel zum Apache-Server ja nur dünn an der Oberfläche. Was im gegebenen Fall auch gewollt ist, weil a) Apache ausführlich dokumentiert ist, b) das Wiki kein 2. Apache-Handbuch sein will (und soll) und c) die konkrete Konfiguration ja von den Programmen abhängt, deren Seiten Apache ausliefert.

Der von dir geschilderte Fall bezieht sich ja auch konkret auf Apache+Wordpress(+PhpMyAdmin). Das kann bei anderen Programmen anders sinnvoll zu konfigurieren sein.

Was du machen kannst: du kannst für den Fall, den du beschreibst, gerne ein Howto schreiben, wo du das, was du für deinen Anwendungsfall schilderst, niedergeschrieben ist. Das Howto würde dann im Apache-Artikel verlinkt.

Gruß, noisefloor

Alles klar, danke für die Rückmeldung, kann ich gerne machen. Gibt's denn grundsätzliche Bedenken? Ich bin mir immer noch nicht ganz sicher, ob ich mir damit nicht ein Loch aufgerissen hab. Könnte ein Angreifer, der PHP-Code eingeschleust bekommt, evtl. das Passwort des Nutzerkontos ändern?