Apache-Neustart absichern gegen Fehler

[masterblupper]

Hallo,

ich hab folgendes Problem und hoffe, dass von euch jemand eine Idee hierzu hat.

Die Umgebung sieht wie folgt aus:
Apache 2.0, PHP 5 mittels Suphp eingebunden, Verzeichnisstruktur: /www/$benutzername/$domain/htdocs bzw. /www/$benutzername/$domain/tmp/
Für die beiden Ordner htdocs und tmp hat jeweils der Benutzer ein Schreib- und Leserecht.

Das Problem ist relativ einfach:
Nachts werden mittels Logrotate die Webserver-Logfiles "bearbeitet" und mittels Script vorher statistisch ausgewertet. Nach dem rotieren und packen der Logfiles wird der Apache mittels "/etc/init.d/apache2 graceful" neu gestartet.

Dies geht natürlich jetzt solange gut, solange wie jeweils der htdocs und logs-Ordner für die Vhosts existierten. Kommt jemand der Nutzer auf die Idee einer der beiden Ordner zu löschen, dann wird es tödlich.

Daher die Frage:
Hat jemand eine Idee, wie ich sicherstellen kann, dass der Apache dennoch weiter läuft?

Meine erste Idee war vorher ein apachectl -t auszuführen und zu schauen, ob es zu einer Fehlermeldung kommt. Das ganze erkennt aber nur, wenn ein htdocs-Verzeichnis fehlt. Fehlt das Logs-Verzeichnis, dann fährt der Apache hoch und beendet sich sobald etwas in das Logs-Verzeichnis geschrieben werden soll.

Eine andere Idee wäre natürlich, vor dem "graceful" einfach "blind" per mkdir die Logfiles-Verzeichnisse neu zu erzeugen. Existiert bereits das Verzeichnis -> gut, wenn nein, dann existiert es danach. Im Anschluss könnte man noch den oben genannten Test starten und man wäre sicher. Aber irgendwie wäre das doch recht unpraktikabel vom Verwaltungsaufwand her. Vielleicht aber wäre das von der Logik her am besten.

Die optimalen Lösung wäre irgendwie zu verhindern, dass entweder die beiden Ordner gelöscht werden oder den Apache zum Neustart zwingen.

Danke an alle, die sich darüber Gedanken machen. Vielleicht hat von euch einer zufällig eine Idee. :-)

[static]

Hi
also ich würde mich da auf gar nichts einlassen. Alle Files die zum Betrieb des Webservers zwingend gebraucht werden, gehören imo nicht in den Verwaltungsbereich des Benutzers.
Also entweder über die Rechte sicherstellen, dass der Benutzer die Dateien nicht löschen kann. Oder die Dateien ausserhalb des für den Nutzer zugänglichen Bereichs ablegen. Falls er dennoch Zugriff darauf braucht notfalls mit Links arbeiten - dann kann er maximal nen Link löschen.

static

[masterblupper]

Hi,

das ist ein Ansatz den ich aktuell jetzt auch verfolge. Das Logverzeichnis kann theoretisch nicht mehr gelöscht werden, da der Nutzer nur noch Leserechte hat (okay, in meinem Fall war das eigentlich bei einem Nutzer nur durch ein Typo meinerseits eingeräumt).

Nur beim htdocs-Verzeichnis sehe ich aktuell kein einfachen Weg, da der Nutzer ja zwangsläufig ein Schreibrecht benötigt und damit auch die Mittel hat, den Ordner zu löschen :-/

[daemotron]

Für das log-Verzeichnis folgende Owner setzen:
user: wwwrun (oder wie dein Apache-User auch immer heißt)
group: webuser1 (oder wie die Gruppe des betreffenden Users heißt)

Als Berechtigung dann 750 auf das Verzeichnis und gut is...

[masterblupper]

Hi,

die Antworten haben auch gerade etwas überschnitten :-)

Das mit dem Logverzeichnis ist klar ... nur stellt sich aktuell halt noch die Frage, wie am besten mit dem htdocs-Verzeichnis verfahren.

[daemotron]

Hab ich auch grad gemerkt
Idee: Owner für htdocs wwwrun, group webuser1 (vorausgesetzt, Du hast pro Webuser auch eine eigene Group eingerichtet).
Berechtigung: 1570
Ergebnis: nur Owner kann löschen, darf aber nicht, da keine Schreibrechte... Group kann in dem Verzeichnis rumschreiben und auch löschen (die Dateien da drin haben ja als Owner dann WebuserXY), kann aber htdocs nicht löschen, da nicht owner...

[masterblupper]

Hi,

hmm, auf das Sticky Bit hätte ich echt selber kommen können (oder müssen ... naja *G*).

Danke jedenfalls für den Tipp ... hat mir sehr weitergeholfen. Manchmal sieht man echt vor lauter Bäumen den Wald nicht mehr :-)

Nachtrag:
Mein Test hat gezeigt, dass der oben erwähnte "Trick" mit dem Sticky Bit nur funktioniert, wenn in dem Ordner mindestens eine Datei des Owners bzw. Roots ist. Wobei dann ja wieder klar ist, dass der Ordner nicht gelöscht werden kann. *kopfkratz* also irgendwie ist bei mir doch gerade noch etwas der Wurm drin. (Irgendwie stell ich mich heute echt zu dämlich an) :-]

[masterblupper]

Sorry für das komplette Edit. Hatte den Fehler gefunden. Anscheinend reagierte aus irgend einem Grund Debian minimal anders auf das Sticky-Bit als Fedora Core.

[djcrackman]

Bei mir sieht die Struktur so aus, da ich auch immer wieder Probleme mit Usern hatte:

Code: Select all

drwxrwxrwt     4 root   root    4096 Jan  7 13:49 djcrackman
  | -> drwxrwx---    12 root   nobody  4096 Jan 23 20:55 pub
  | -> drwxrwx---     2 root   nobody  4096 Jan 23 07:10 tmp

[masterblupper]

Hi,

yup, ähnlich siehts hier jetzt auch aus:

Code: Select all

/www/$accountname/                    www-data:$gruppedeskunden   drwxrwx--T
/www/$accountname/$domainname/        www-data:$gruppedeskunden   drwxrwx--T
/www/$accountname/$domainname/htdocs  www-data:$gruppedeskunden   drwxrwx--T
/www/$accountname/$domainname/tmp     www-data:$gruppedeskunden   drwxrwx--T
/www/$accountname/$domainname/log     www-data:$gruppedeskunden   drwxr-x--T

Damit ist wieder, wie vorher auch, relativ sichergestellt, dass der Accountinhaber auch nicht so einfach in den Ordner von anderen Accounts kommt. Wobei es natürlich immer wieder welche gibt die mit den Rechten sehr großzügig sind (0777). Aber ich lass mir als regelmäßig alle Ordner/Dateien ausgeben, welche "world writeable" sind und spreche dann den Accountinhaber entsprechend darauf an.

Man kann im Endeffekt zwar viel tun um die Sicherheit hoch zu halten, aber eine 100%ige Sicherheit findet sich nie. Der nächste Schritt den ich jetzt angehen werde ist auf jeden Fall evntl. die Vhosts in eine Chroot-Umgebung zu bringen. Was mir die letzten 1-2 Jahre gezeigt haben (beim Thema Rootserver und Sicherheit) ist, dass es a) Webhoster gibt die das sehr lasch sehen (Stichwort: mod_php etc.) und b) dass man immer wieder eine Kleinigkeit zum nachbessern findet.

Gruß,
MasterBlupper