Webserver - gesucht Tipps für das Setzen der "richtigen" Berechtigungen für Verzeichnisse/Dateien nach der Installation

Na dann hast Du jetzt viel Arbeit, denn alle Dateien (außer diejenigen im konfigurierten files-Verzeichnis) sollten die Rechte 644 und alle Ordner (außer das von Dir konfigurierte files- und temp-Verzeichnis) 755 haben. Rekursiv.

Einfacher würde sein, bis auf die settings.php (im Verzeichnis /sites/default) alles zu löschen und per FTP nochmals hochzuladen, dann sollten die Rechte von alleine stimmen, wenn der Hoster keinen Quatsch gemacht hat. Dann die settings.php an ihren Ort zurückkopieren und den tmp- als auch files-Ordner auf 777 setzen. Dies alles gilt unter der Voraussetzung, dass Dein Hoster mod_php einsetzt.

Warum hat er Dir denn um alles in der Welt alle Dateien auf 777 gesetzt - wo war das Problem? Drupal benötigt während der Installation nur Schreibrechte im Ordner default unterhalb von sites; also diesen allein auf 777 gesetzt zu haben, hätte zu einer erfolgreichen Installation führen sollen und hätte von Dir am besten ohne Hoster im FTP-Client erledigt werden können - unter normalen Umständen natürlich. Gab es so eine Meldung beim allerersten Installationsversuch, dass da die Rechte fehlen? Hast Du dann Deinen Hoster um Hilfe gebeten und er hat diesen Schrotflintenschuss mit dem "alle Dateien 777" getätigt? Sehr kurios, das.

Hallo tumblingmug,

das ist ja endlich mal eine gute Erklärung zu den Dateirechten! Da habe ich lange danach gesucht.

Trotzdem habe ich noch ein paar Fragen, denn auf meinem Debian-Server sieht es etwas anders aus.
Bitte nicht böse sein, wenn die Fragen vielleicht etwas "dumm" sind, aber mit Unix hatte ich bislang noch nix zu tun.

1. Wie wird beim Upload erkannt, welche Datei welche Dateirechte erhalten muss? Muss man dazu das Original-Drupal-Paket hochladen oder reicht es aus, sich eine lokale Installation auf einem Windows-System einzurichten, dort alles fertig zu konfigurieren und anschließend einen Upload dieser Dateien zu machen (so wie ich das getan habe)?

2. Bei mir haben alle Verzeichnisse beim Upload die Rechte 775 (statt 755 wie Du schreibst) und die Dateien 664 (statt 644) erhalten. Ist das ok oder muss ich das ändern (wenn ich Wert auf möglichst große Sicherheit lege)?

3. Welche Bedeutung haben denn eigentlich die Gruppenrechte? Bei mir ist zwar eine Gruppe angelegt, ich habe aber keine Möglichkeit diese Gruppe zu verändern oder deren Benutzer einzusehen.

4. Du schreibst, dass das files-Verzeichnis 777 benötigt. Bei mir hat es - und alle darin befindlichen Unterverzeichnisse - aber auch nur 775. Trotzdem funktioniert der Upload (insb. mit dem Image-Modul) problemlos. Was kann da los sein?

5. Ich beschreibe innerhalb eines Moduls eine log-Datei mit fopen, fputs und fclose. Diese hat sogar nur 644, wird aber trotzdem fleißig beschrieben. Was kann da los sein?

Es wäre echt lieb, wenn Du (oder ein anderer Experte) antworten würde. Denn solange diese Fragen nicht geklärt sind, traue ich mich nicht, die Seite frei zu schalten.

Falls es kein Versprecher ist und mit Unix eigentlich Linux gemeint ist. Aber Beides kann Dir eigentlich relativ egal sein.

Mehrere Moeglichkeiten bestehen. Normalerweise wird der FTP Server entsprechend konfiguriert um die Dateirechte hochgeladener Dateien zu setzen - muss und kann Dich also nicht kuemmern.

Bei entsprechender Konfig des FTP-Server vorrausgesetz kann man auch im FTP-Programm einstellen welche Rechte beim Upload die Dateien bekommen wen sie oben angekommen sind.

Da Du wohl Windows verwendst kannst Du die lokalen Drupal-Dateien nicht bezueglich ihrer Rechtekonfiguration aendern. Sie koennen also nur so auf den Webserver hochgeladen werden wie Du die Drupal-Dateien selbst heruntergeladen hast.
Anders bei Linux auf Deinem lokalen Rechner. Da kannst Du Rechte an den Drupal-Dateien aendern.

Naja, eigentlich reicht auch 775.

Meist wird aus Bequemlichkeit 777 genannt. Die dritte 7 bedeutet ausfuehrbar - Dateien im Ordner oder eine Datei selbst. Bei einer Drupalinstallation ist eine Ausfuehrbarkeit von Dateien normalerweise nicht Vorraussetzung - wenn PHP auf dem Webserver nicht als CGI laeuft.

Fuer Dein Verstaendnis der Rechte.

Die 3 Ziffern wie 664 oder 777.

1. Ziffer: Der Besitzer der Datei/Ordner
2. Ziffer: Die Gruppe der Datei/Ordner
3. Ziffer: Alle Anderen als 1. und 2. - also Jeder

Wenn man Wert auf groesstmoegliche Sicherheit legt sollten die Rechte an Ordnern und Dateien immer nur so hoch wie noetig gesetzt werden. Konfigurationsdateien wie die settings.php sollten daher immer 644 haben - nur der Dateieigentuemer darf sie beschreiben und Jeder kann sie lesen.

777 dagegen bedeutet Jeder hat alle Rechte an einer Datei/Ordner mit dem Zusatz der Ausfuehrbarkeit. Ausfuehrbarkeit bedeutet Dateien welche vom Code her Scripte sind koennen nur mit 777 ausgefuehrt werden.

 
PS

Es gibt HowTo's im Netz zum Rechtesystem von Unix/Linux.

Eventuell wird Dir durch diesen Thread deutlich wo eine der Wurzeln liegt das Unix/Linux Systeme vom Grunde her sicherer sind als Windows Systeme.

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Nein. Der Unterschied von einer "5" zur "7" für einen Rechteinhaber liegt nicht in der Ausführbarkeit, sondern im Schreibrecht. "7" enthält auch das Schreibrecht und "5" enthält es nicht. Hingegen muss ein Ordner ausführbar sein, sonst kann sein Inhalt nicht gelistet werden.

Zur Verdeutlichung: "4" oder auch "r" bedeutet Leserecht, "2" oder "w" ist das Schreibrecht und "1" oder "x" ist das Recht, eine Datei auszuführen (nur bei Shell-Skripten oder Binaries sinnvoll, nicht jedoch bei Drupal's PHP-Skripten, denn die werden einem ausführbaren Programm nur übergeben und müssen dafür zumindest lesbar sein = "4"), aber bei Ordnern gibt die "1" das Recht, deren Inhalt zu listen bzw. sie zu betreten (absolut notwendig für Drupals files-Ordner).

Die Dreiergruppe der Rechteinhaber von Dateien und Ordnern unter unixartigen Betriebssystemen wie Linux ist natürlich wirklich hochgradig geeignet für Konfusionen, wenn es um Shared Hosting geht. Generell muss man sagen, dass prinzipiell der "Rest der Welt" (die 3. Zahl der Dreiergruppe) am sichersten mit einer "0" (Null) bedient würde, sprich: gar keine Rechte bekommen dürfte. Warum auch sollte mein Webhosting-Nachbar mittels eines PHP-Skripts meine settings.php auslesen dürfen??

@Smitty: je weniger Rechte für den "Rest der Welt" vergeben werden, desto besser. Dennoch ist auch Deine Rechte-Situation selten anzutreffen: man könnte vermuten, dass Dein Hoster für die "Gruppe" darum Schreibrechte setzt, weil ihr der Webserver Apache angehört. Dann (kannst Du ja mal testen) würde sogar 770 für den Files-Ordner funktionieren. Wie heißt denn die Gruppe Deines Files-Ordners?

Was mir nicht ganz klar ist: wenn bei Dir PHP als CGI läuft, dann braucht die Gruppe keine Schreibrechte. Läuft aber mod_php (PHP als Apachemodul), dann hat, selbst wenn Du 770 setzen kannst, eigtl. jeder Shared-Hosting-Nachbar Schreibrechte auf Deine files ...

Rechte Wirrwarr

@quiptime: Erst mal herzlichen Dank für deine Schnelle und umfangreiche Antwort.

Ich bin halt davon ausgegangen, dass bezüglich der Rechte beim Unixderivat Linux die gleiche Regeln gelten wie bei Unix. Spielt aber wirklich keine Rolle!

@tumblingmug: Ebenfalls herzlichen Dank!

So hatte ich das mit den Dateierechten auch verstanden! Deswegen hat es mich ja gewundert, dass die Dateien ohne Schreibrecht für den "Rest der Welt" beschrieben werden können.

@all: Inzwischen hat mein Provider festgestellt, dass er einen Fehler auf der Serverseite hatte, wodurch die Dateirechte beim Upload falsch gesetzt wurden. Den hat er nun behoben und ich habe die Dateien neu hochgeladen. Jetzt haben alle Verzeichnisse 755 und alle Dateien 644.

Was mich allerdings sehr wundert und verunsichert, ist die Aussage meines Providers, dass auch für das files-Verzeichnis 755 reicht. Er sagt, das hänge mit der Betriebsart des Accounts zusammen. Ich habe mal mit 700 getestet. Auch da funktioniert der Upload problemlos. ???

Jetzt frage ich mich natürlich, ob jetzt alle Dateien über php und/oder sonstige Scripten geändert werden können, wenn Schreibrechte hierzu gar nicht erforderlich sind.

Nachdenklich macht mich auch die Aussage von tumblingmug, dass eigentlich auch eine „0“ für den "Rest der Welt" reichen müsste. Ich dachte eigentlich der für den "Rest der Welt" wäre der Webserver bzw. Drupal. Habe ich da etwas falsch verstanden? Und wenn mein Webhosting-Nachbar bei einer „4“ schon meine Dateien auslesen kann, was kann der denn dann noch alles, wenn zum Verändern der Dateien gar keine Schreibrechte erforderlich sind?
Wobei: Dann müsste ich doch eigentlich auch die Dateien meiner Webhosting-Nachbarn sehen können? Wie geht denn das?

Auch mit den Gruppen stehe ich auf Kriegsfuß: Wozu brauche ich die eigentlich? Es gibt in meinem Account einen Benutzer und eine Gruppe, die so heißt, wie der Benutzer, aber einen Buchstaben („g“für gruppe) mehr hat.
Ich kann aber weder die Gruppe ändern noch eine neue Gruppe anlegen. Noch kann ich sehen, wer alles Mitglied in der Gruppe ist.

Gleich noch eine Frage zur .htaccess:

Dort werden mit

ja die Dateien vor dem Auslesen geschützt. Mir ist aber aufgefallen, dass die Endungen txt, tmp, pot und ini nicht geschützt werden. Ist das beabsichtigt, sprich: müssen die einsehbar sein, oder wird (zumindest bei txt und pot) davon ausgegangen, dass man die gar nicht auf dem Server hat?
Und: Wäre es nicht sinnvoller, alles auf deny zu setzen und dann nur die Dateien freizugeben, die man wirklich braucht (css, js, png, gig, jpg, ...)?

Gerade habe ich erfahren, dass mein Account auf dem Shared Server in einer Chroot Umgebung läuft. Dabei läuft der Apache unter dem Loginnamen des Accounts und auch die Dateien und Ordner gehören dem Account. Und somit ist der Apache, allein durch die Ownerrechte berechtigt, alles zu tun (lesen, schreiben, ausführen).

Das heißt doch andersrum, dass "Gruppe" und "Welt" völlig irrelevant werden? Damit kann ich eigentlich alle Dateien genausogut auf 600 und alle Verzeichnisse auf 700 setzen, ohne dass Drupal in seiner Funktionalität beeinträchtigt wird?

Stellt es dann nicht ein Sicherheitsrisiko dar, wenn der Owner (und damit der Webserver) das Recht 6 bzw. 7 hat? Denn wenn auf irgendeine Weise Schadcode in das System eingeschleust wird, kann ja jede Datei überschrieben werden!??!

Macht es da Sinn, die Dateirechte grds. auf 400 und die Verzeichnisse auf 500 zu setzen? Oder bekomme ich dann irgendwelche Probleme? Dumm ist natürlich, dass ich die Dateien dann per FTP nicht mehr updaten kann, da mir dann ja die Schreibrechte auf diese Datei fehlen. Seltsamerweise kann ich sie per FTP aber weiterhin löschen??

... und einfach leider wirklich unzureichende Ausgangsinfos für eine (vielleicht) umfangreiche Antwort. Ich bitte also um folgende Infos:

• den Namen des Dateibesitzers für per FTP hochgeladene Dateien
• den Namen des Dateibesitzers für per PHP-Skript-Upload hochgeladene Dateien
• den Namen der Gruppe für per FTP hochgeladene Dateien
• den Namen des Gruppe für per PHP-Skript-Upload hochgeladene Dateien
• die vergebenen Rechte für Dateien + Ordner nach FTP-Upload
• die vergebenen Rechte für Dateien + Ordner nach PHP-Skript-Upload

Du kannst solche Angaben hier in einem öffentlichen Forum ruhig leicht verfälschen, z.B. falls da im Namen des Dateibesitzers Zahlen oder wilde Buchstabenkombinationen vorhanden sind, müssen die hier nicht 100%ig stimmen - im Falle von Namen wie "www-data" oder "nobody" o. ä. bitte die Angaben nicht verfremden.

• Namen des Dateibesitzers für per FTP hochgeladene Dateien: xy4567
• Namen des Dateibesitzers für per PHP-Skript-Upload hochgeladene Dateien: xy4567
• Namen der Gruppe für per FTP hochgeladene Dateien: xy4567g
• Namen des Gruppe für per PHP-Skript-Upload hochgeladene Dateien: xy4567g
• Vergebene Rechte für Dateien + Ordner nach FTP-Upload: 644 für Dateien und 755 für Ordner
• Vergebene Rechte für Dateien + Ordner nach PHP-Skript-Upload: 664 für Dateien und 755 für Ordner

Der Provider sagt: Der Apache läuft unter dem Loginnamen des Benutzeraccounts.

Interessant.
Kann der Apache z.B. Grafikdateien anzeigen, deren Rechte Du auf 600 setzt? Kannst Du das mal ausprobieren?
Falls nicht: kann er Dateien anzeigen, deren Rechte auf 640 stehen?

Ich habe mal eine jpg-Datei auf 600 gesetzt. Sie wird vom Image-Modul problemlos im entsprechenden Knoten angezeigt.

Da also der Apache mit der User-Kennung "xy4567" gestartet ist, welche zugleich auch die FTP-Userkennung und die Nutzer-Kennung des gestarteten PHP-Binary ist, sind natürlich überhaupt keine Rechteprobleme zu erwarten. Das ist so eine sehr sehr seltene Konstellation im Shared Hosting. Die Gruppenzugehörigkeit der Dateien und Skripte spielt infolgedessen gar keine Rolle.

Dennoch sollten die settings.php auf 600 sowie das files- und tmp-Verzeichnis auf 755 gesetzt werden (oder sogar besser auf 700). Denn "alle Welt" - und das bezieht sich aber nicht etwa auf Gäste oder angemeldete User Deiner Drupal-Site, sondern auf andere Benutzer des Hosting Servers - "alle Welt" sollte in so einer "Hosting Oase" keinesfalls Schreibrechte eingeräumt bekommen.

Die .htaccess im files-Verzeichnis muss im Drupal-Originalzustand sein, damit nicht die angemeldeten Benutzer mit Upload-Rechten über eine Hintertür beliebige Skripte auf Deiner Site ausführen dürfen. Ich würde auch die originale .htaccess im Drupal-Installverz. nicht ändern - das Deny auf nur die drupalspezifischen Ordner und Files ist in Ordnung und sollte, wenn das Bedürfnis besteht, eher auf drupal.org diskutiert werden.

Eine Frage: welcher Hoster bietet das so an? Oder bist Du Dein eigener Hoster?

Hallo tumblingmug!

Erst mal herzlichen Dank für Deine Ausführungen.

Ich habe inzwischen auch lange mit dem Support diskutiert und der hat endlich zugegeben, dass es eigentlich keinen Grund gibt der Gruppe und der Welt irgendwelche Rechte zu geben (trotzdem empfiehlt er weiterhin 755 für Verzeichnisse und 644 für Dateien). Daher überlege ich nun, ob ich die Verzeichnisse auf 700 und die Dateien auf 600 setze. Oder habe ich dann irgendwelche Probleme zu erwarten?

Was mich noch wundert, ist, dass die per FTP hochgeladenen Dateien die Standardeinstellung des Hosters (644) erhalten, die, die über das Image-Modul hochgeladen werden, aber 664. Da setzt das Image-Modul die Rechte in Zeile 929 explizit. Jetzt frage ich mich, ob ich das ändern sollte?

Mit Drupal-Originalzustand meinst Du sicher den Inhalt der .htaccess-Dateien und nicht deren Dateirechte? Die htaccess im files-Verzeichnis hat bei mir nur 3 Zeilen, die ich ehrlich gesagt nicht ganz verstehe. Daher werde ich hier bestimmt nichts ändern. Bei der Drupal-Installverz. Sehe ich allerdings nicht, warum ich nicht noch txt, tmp, pot und ini hinzufügen sollte. Denn Diese Dateien können momentan ausgelesen werden, was ich insb. bei tmp und ini als Sicherheitsrisiko sehe. Bei txt und pot überlege ich, ob ich die nicht ohnehin löschen sollte (dann besteht diesbezüglich kein Sicherheitsrisiko mehr und es werden ein paar Byte Speicher gespart). Was meinst Du dazu? Auf drupal.org habe ich die Frage schon gepostet (http://drupal.org/node/293892), aber bislang interessiert sich noch niemand dafür.

Ein weiteres Sicherheitsrisiko sehe ich bei der vom Provider gewählten Einstellung darin, dass der Webserver immer und überall Schreibrechte hat und somit jeder ins System eingeschleuste Schadcode jede Datei ändern kann. Andererseits kann ich dem Benutzer aber auch nicht die Rechte entziehen, weil sonst zu befürchten steht, dass ich anschließend nicht mal mehr per FTP darauf zugreifen kann. Vom Provider (ist übrigens WebhostOne) bekomme ich zu diesem Problem nur ausweichende Antworten. Wie siehst Du das: ein echtes Risiko oder ein Hirngespinst?

Die Empfehlung ist OK. Man muss sich doch einmal ansehen, was hier eigtl. "alle Welt" bedeutet. Jeder surfende Gast auf Deiner Site, jeder angemeldete Benutzer auf Deiner Site hat die Rechte des Users und Dateibesitzers "xy4567" und nicht etwa nur diejenigen "aller Welt". Überrascht das? Dies ist einfach darum so, weil der Apache bei WebhostOne unter dieser Benutzerkennung läuft und "alle Welt" Requests an den Apache senden kann.
Was oder wer aber ist dann "alle Welt"? Das sind alle Benutzer oder Programme mit Benutzerkennungen auf diesem Shared Hosting Server Deiner Drupal-Installation, die nicht Apache-Requests oder indirekt PHP-Skripte Deines Webauftritts starten und also nicht der Besitzer und der Gruppe der betrachteten Dateien/Ordner Deiner Site sind.

PHP- und sonstige Skripte aber bringen einen Server in Gefahr. Jede Sicherheitslücke kann sich mörderisch auswirken, wenn sie gekonnt ausgenutzt wird. Das ist ja auch Deine Angst und der Hintergrund all Deiner Fragen. Denn dann ist der Attacker der Dateibesitzer z.B. mit dem Recht, alles ihm einfallende PHP ausführen zu lassen. In dieser Situation aber hilft Dir ein chmod 700 auf eine Datei gar nichts. Und genau für diese Situation hat sich Dein Provider etwas Besonderes einfallen lassen: er sperrt Dich und auch Deine Nachbarn in jeweils einen chroot-Käfig. Damit bist Du überdurchschnittlich sicher vor Deinen Nachbarn und den Attackern Deiner Nachbarn. Das ist sehr viel und zugleich viel viel mehr, als üblichweise an Sicherheit im Shared-Hosting-Bereich gegeben werden kann. Ohne chroot-Käfig wird "alle Welt" sehr viel wichtiger, denn dann gehören alle Deine Nachbarn dazu, von denen immer irgendwie, an Sicherheitsmaßnahmen vorbei, Übergriffe ausgehen könnten.
Bei kritischen Dateien wie der settings.php rate ich dennoch zu chmod 600, da selbst im Falle eines Nachbar-Ausbruchs aus seinem chroot-Käfig diese Zugriffssicherheit noch wirken würde.

Der Apache liefert Dateien aus - an sich nichts ungewöhnliches: deswegen wurden diese ja auf einen öffentlichen Webspace hochgeladen, richtig? Sie sollen doch sicht- und abrufbar sein, was hätten sie sonst dort zu suchen? Und das ist der Grund, warum Deine Bedenken bzgl. .htaccess + deny etc. nicht die meinigen sind: Drupal schützt seine Programmlogik, sofern sie nicht unmittelbar zum Webangebot gehört. Warum sollte Drupal ini- oder txt-Dateien schützen? Es stellt 1.) keine zur Verfügung (und wenn ja, können sie ohne weiteres einsehbar sein) und 2.) ist es viel wahrscheinlicher, dass Textdateien als solche auf einen öffentlichen Webspace geladen werden, damit sie dort abrufbar sind. Sollen sie das nicht sein, gehören sie andererseits und im eigentlichen Sinne nicht in den DOCUMENT_ROOT.
Und ja - Dateien, die Du dort nicht willst, solltest Du löschen.

Gut so.

Die wahre und letzte Sicherheit ist immer das Backup und besteht in der Automatisierung von Backups, weil man das manuell, auf lange Sicht gesehen, entweder immer wieder vergisst oder verschiebt. Vandalen gibt es nun einmal; Du kannst Dir auf der Straße ein blaues Auge holen und mit öffentlich zur Verfügung gestellten Daten eben auch. Dass in so einem Falle eine Versicherung besteht (ein Backup) ist essentiell. Auch ein für Drupal + Module aktiviertes Update-Modul bzw. installiertes update_status-Modul gehört dazu. Muss ich Dir bestimmt nicht sagen, da Du sehr sicherheitsbewußt bist.
Mit der Wahl des Providers hast Du aber, wie es aussieht, schon sehr viel für die Sicherheit getan. Der praktiziert ein total unübliches, seltenes und plausibles Sicherheitskonzept. Die Mehrarbeit, die er sich bei der Konfiguration bis hin zum Einarbeiten dieses Konzepts in das Admin-Panel angetan hat, muss man würdigen.

Wenn ich das richtig sehe, ist das eigentlich „niemand“, bis auf eventuelle „Ausbrecher“. OK, dann ist es eigentlich völlig egal, welche Dateirechte hier gesetzt werden.

Das werde ich machen.

Genau das ist mein Problem. So schön die Käfighaltung ist, führt sie doch dazu, dass jeder Benutzer der Seite alle Rechte auf das Dateisystem hat, falls in der Applikation ein Fehler ist, und das kann man nie ausschließen. Man beachte nur die Häufigkeit der Sicherheitsupdates von Dupal Core. Und ich gehe davon aus, dass es bei den Modulen noch viel schlimmer aussieht, nur dass dort die Fehler nicht immer bemerkt werden.

Da frage ich mich, wem ich mehr vertrauen kann: Den Hosting-Nachbarn (ok, wenn deren Seiten angegriffen werden, kann sich das jetzt nicht mehr auf meine Seite auswirken, was ja auch sehr gut ist) oder den bösen Fremden aus dem Web. Aber einen Tot wird man wohl sterben müssen. Und wenn man sich des Risikos bewusst ist, ich das – denke ich – auch schon mal was.

Na ja, auf die ini und pot Dateien bin ich gekommen, weil es sich dabei um Drupal-Dateien handelt: ini wird vom vom gmap-Modul benutzt und pot von den Übersetzungen.
Bei den txt-Dateien hast Du natürlich recht. Problematisch ist m.e. nur, dass (insb. bei den Modulen) tonnenweise txt-Dateien enthalten sind. Und wenn die ausgelesen werden können, hat der Angreifer u.U. alle Informationen, die er für seinen Angriff braucht. Insb. wenn es sich um api-Beschreibungen usw. handelt.
Aber wenn man etwas nachdenkt, kommt man zu dem Schluss, dass txt, po und pot wirklich nichts auf dem Server verloren haben. Sie belegen nur Speicher und stellen ggf. ein Sicherheitsrisiko dar.
Bleiben also nur noch die ini und die tmp. Bei denen sehe ich aber ein echtes Risiko, weil insb. die tmp Konfigurationseinstellungen aus der Administration enthalten können.

Kennst du denn ein Script, mit dem man bestimmte Verzeichnisse / Verzeichnisbäume automatisiert / zeitgesteuert zippen und downloaden kann? Ich habe da bislang noch nichts gefunden (aber auch noch nicht intensiv gesucht).

Ja, so ist es. Eine wahre Update-Orgie im Laufe von Monaten. Dann kommt dazu, dass plötzlich bei einem Contributed Modul eine Funktionalität wegfällt, also die Updates auch noch recherchiert und getestet werden müssen, wenn man sein eiinstiges Drupal-Konstrukt nicht gefährden will - mühsam. Die Folge ist, dass Du aufgrund von profanem Zeitmangel jede Menge alter (bewährter) Module am Laufen läßt und nur noch die Sicherheitsupdates ernstnimmst. Doch das ist eine Notstrategie und nicht empfehlenswert.

Ich kenne nur ein GPL-Tool, das die DB inkl. (allerdings unkomprimierter) Dateien via FTP komplett zeitgesteuert sichern kann: http://www.phpmybackuppro.net/
Mit einem eingerichteten Cronjob kann man dann ganz gut schlafen.

Herzlichen Dank für den Link. Ich werde das Tool ausprobieren, sobald ich wieder ein wenig mehr Zeit habe.

Apropos probieren: Ich habe mal getestet, was passiert, wenn man einem Verzeichnis das Recht 500 und einer Datei das Recht 400 gibt. Auch der Benutzer (in unserem Fall damit also auch der Webserver) kann die Datei dann nicht mehr verändern, überschreiben oder löschen.

Trotzdem kann ich als Benutzer die Rechte jederzeit wieder auf 700, 600 oder einen anderen Wert zurückändern. Ist das normal oder eine Folge dieses speziellen Konzepts des Providers? Kann ich also erwarten, dass das immer funktioniert? Oder muss ich damit rechnen, mich mit einer solchen Aktion irgendwann selbst auszusperren?

Bei domainfactory habe ich nämlich gelesen:

Aber die fahren ja auch ein anderen Konzept. Sollte man trotzdem die Finger davon lassen?

Würde ich so machen. Alle Rechte die Du nach Entzug Dir selber wiedergeben kannst, kann sich auch ein Attacker per chmod wiedergeben. Du kannst es drehen wie Du willst: Deine Rechte sind zugleich die Rechte eines Einbrechers, wenn er einmal in der Wohnung steht – und sie sind immer genug, um Unheil zu stiften. Also schließe die Versicherung ab, mache Deine Backups und bete :-)

Da hatte ich nicht dran gedacht. Ist aber plausibel. Dann werde ich mich jetzt mal um das Backup kümmern.

Nur noch zum Verständnis: Ist das Recht, Dateirechte zu ändern, unter Linux eigentlich ein separates Recht, das dem Account auch wieder entzogen werden kann, so dass der Eigentümer der Dateien, die einmal eingestellten Rechte nicht mehr ändern kann?

Und noch eine Verständnisfrage, die mir im Kopf umgeht: Habe ich das richtig verstanden, dass der chroot-Käfig eine komplette Linux-Umgebung beinhaltet, sich also nicht nur auf den "Besitzer" beschränkt, sondern auch seine eigenen "Gruppen" und seine eigen "Welt" beinhaltet, so dass der einzelne Hosting-Kunde mit seinen Nachbarn eigentlich gar nichts gemeinsamen hat, außer dass sie sich gemeinsam auf einer (physikalischen) Maschine befinden?

Wer einen Shell- oder FTP-Zugang unter Linux hat, darf gewöhnlich Dateirechte für eigene Dateien ändern. Wenn Du allerdings fragst, ob man nicht doch noch etwas Security-"Hardening" leisten kann, dann ist das mit Zugriff auf die php.ini (und sogar httpd.conf) natürlich möglich: http://www.heise.de/security/Grundsicherung-fuer-PHP-Software--/artikel/...

Nein. Chroot und Vserver (das beschreibt Dein letzter Nebensatz) sind immer noch zwei verschiedene Dinge: http://de.wikipedia.org/wiki/Chroot

Super! das ist genau das, was ich gesucht habe! Leider habe ich nichts gefunden, was wirklich verlässlich aussagt, welche Einstellungen Drupal braucht und was man beruhigt abschalten kann. Ich habe jetzt mal folgende Einstellungen gesetzt:

register_globals = Off
allow_url_fopen = Off
safe_mode = On
disable_functions = chmod, show_source, system, passthru, shell_exec, exec ,popen, escapeshellcmd, proc_nice, ini_restore

Damit sollte nochmals einiges an Sicherheit gewährleistet sein. Und jetzt kann ein php-Script auch keine Dateirechte mehr ändern.

Außerdem habe ich in http://cvs.php.net/viewvc.cgi/php-src/php.ini-recommended?revision=1.228... gelesen, dass die folgenden Einstellungen Performance-Gewinne bringen sollen:

output_buffering = 4096
register_argc_argv = Off
auto_globals_jit = On

Nicht ganz sicher bin ich mir, ob die folgenden Einträge sich nicht mit den Einstellungen von Drupal unter Verwalten > Einstellungen > Fehlermeldungen ins Gehege kommen:

display_errors = Off
log_errors = On
error_reporting = E_ALL

Nun werde ich erst mal testen, ob sich mit diesen Einstellungen irgendwas anders verhält als vorher.

Na, dann habe ich das jetzt (hoffentlich) auch endlich richtig verstanden. Eingesperrt ist also nur die Applikation, d.h. der Webbserver. Soweit Dateien Leserechte für Gruppe und Welt haben, können Sie also auch weiterhin von den übrigen Nachbarn gesehen werden, sind aber keinen Angriffen auf deren Webserver ausgesetzt, da die ja eingesperrt sind. Allerdings habe ich keine Ahnung, was ich machen müsste, um die entsprechenden Dateien der Nachbarn mal sehen zu können.

Leider musste ich wieder
safe_mode = Off
setzen, weil sonst Imagemagick nicht funktioniert. Auch safe_mode_exec_dir = /usr/bin/convert hat nichts geholfen.

Soll aber schon Leute gegeben haben, die das hingebracht haben - allerdings nicht unterhalb wochenlanger Tests :(
-> siehe http://www.typo3.net/forum/list/list_post//69553/ (3. Beitrag)

Erst mal sorry für die lange Funkstille. Ich war unterwegs und wollte mal versuchen, nur mit einem Handheld auszukommen. Hat im Prinzip auch funktioniert. Aber hier im Forum konnte ich nur lesen, nicht aber schreiben.

Vielen Dank für den Hinweis zum save_mode. Ähnliches hatte ich auch schon gesehen. Es muss also gehen! Allerdings steige ich bei den dazu notwendigen Einstellungen noch nicht ganz durch. Vielleicht komme ich mal in einer ruhigen Stunde dazu, das alles mal genauer zu studieren und zu experimentieren. Doch im Augenblick übersteigt das meine Fähigkeiten.