/temp und config.php mit absolutem Serverpfad - bitte

[evaki]

Mit Symlinks könnt' ich hier auch, geht dann aber nicht mehr bei "Billig-Paketen.
Mit Dateirechten + Webuser geht auf Serverebene ja auch noch was, da braucht's aber dann auch ein Script zur Überprüfung derselben.
Es schwebt mir tatsächlich 'ne Möglichkeit wie bei OwnCloud vor; also wenn Voraussetzungen stimmen, dann nachträglich Änderungsmöglichkeit nutzen können. Das bekommt dann möglicherweise auch noch der First user hin.

Wenn ich recht erinnere, wurde die Idee hierzu mit der Benutzung des Downloadmoduls zum erstenmal vorgetragen.
Nun gut, dann man'en schönen Wochenende, - Evaki.
ps. Mit "eigenem" Server (oder auch anne Uni) lassen sich diese Forderungen in Sachen Sicherheit natürlich leichter - teilweise schon auf der Dateisystemebene - umsetzen, ohne am CMS fummeln zu müssen. Nun isses abba nich so...     

[DarkViper]

na, Session wird da nicht benötigt.
Z.B. Typo3, da wird der Core per Shell in z.B. /opt/... installiert und dem Verzeichnisbaum Leserechte für den Webserver vergeben. So brauchts bei 50 Hostings nur einen gemeinsamen Typo3-Core, der per Softlink eingebunden wird. Deeplink darauf ist nicht möglich.

[evaki]

>>Bei meinen Servern kein Problem, die sind passend konfiguriert.
Jep, unsere eben auch 
>>dadurch könnte man bei Shared-Hostings u.U. recht einfach auf die Verzeichnisse eines benachbarten Paketes zugreifen und dessen Daten manipulieren.
Ist mir bekannt, auch schon vor sehr sehr langer Zeit so erlebt, weshalb das WB-eigene \Temp dafür "eigentlich" die Lösung darstellt. Nur hatte ich heute bei einem Anwender kurz reingeschaut (DirectoryIndex off - soll so sein...), und dort keine Beschränkung per htaccess*** gefunden.
Ob das "normal" ist, weiß ich jetzt nicht. Falls dem so ist wäre ein Hinweis in der DOC vielleicht sinnvoll, damit der Anwender bei solch einer Konstellation eine anlegen kann/soll - Direktive halt serverspezifisch.
Ob wer jemals vor der Installation in's DOC reinschaut??? Und nachher???

Ich erinnere, ist auch schon wieder eine Bartlänge her, daß bei OwnCloud nach der Installation die Option das Dateienverzeichnis außerhalb root zu legen möglich war - eben nachträglich, so daß sich das jeder passend (Hosting-Paket) einstellen konnte.
MfG. Evaki

*** war da nicht irgendwas mit an Session gebunden, oder narrt mich die Erinnerung?

[DarkViper]

Für die config.php würde das bedeuten, dass sie ausserhalb des DocumentRoot liegen müsste, damit man nicht mehr direkt darauf zugreifen kann. Ebenso das /temp Verzeichnis.
Und hierbei geraten wir in teils heftige Schwulitäten..
Die Core-Anpassung wäre prinzipiell eine Kleinigkeit. Das Hauptproblem sind die x hoch n unterschiedlichen Konfigurationen der einzelnen Webspaces.
Bei meinen Servern kein Problem, die sind passend konfiguriert. Bei Hostingpaketen "von der Stange" jedoch ist meist DocumentRoot schlicht die Root des Webspaces und Zugriffe auf darüberliegende Verzeichnisse sind durch den Server unterbunden. Grund: dadurch könnte man bei Shared-Hostings u.U. recht einfach auf die Verzeichnisse eines benachbarten Paketes zugreifen und dessen Daten manipulieren.
Ein sehr vereinfachtes Beispiel von vielen: 
Der allgemeine Pfad zur DocumentRoot eines Hosting lautet: 
/var/www/meine.domain/httpdocs/
zu einem anderen Hosting dann:
/var/www/andere.domain/httpdocs/
Ist der Server jetzt ungesichert, kann mit PHP z.B. durch  include WB_PATH.'/../../andere.domain/httpdocs/wb/config.php'; problemlos auf die Einstellungen einer völlig fremden Domain zugegriffen werden. (dieser Code könnte übrigens von jedem der das Code oder Code2 Modul bedienen darf eingegeben werden... oder in die index.php eines Templates einbauen.. oder oder..)
Aus diesem Grund sind fast alle Webspaces so abgesichert, dass keine Cross-Domain-Aufrufe erfolgen können. (was früher mit PHP als Apache-Modul noch sehr häufig passieren konnte)

Gut, selbstverständlich gibt es aber Möglichkeiten, die config.php entsprechend auszulagern. Nur benötigt man da meist auch Root-Zugriff auf den Server um  Softlinks in ein übergeordnetes Verzeichnis anzulegen, in dem die config dann abgelegt wird. Apache kann dann zwar darauf zugreifen, jedoch ist kein Deeplink per http:// mehr möglich.
Also optimal?  Definitiv nein! Denn damit wird WB auf fast allen Shared-Hostings mangels Zugriffsrechten nicht mehr installierbar.
Die config irgendwo zwischen den anderen Dateien "verstecken"? Das selbe Problem. Ein Lösungsansatz wäre, die Datei nicht mehr als PHP-Datei zu includen, sondern als z.B. ini-Datei einzulesen. Aber sie würde immer noch irgendwo stecken, wo sie direkt aufgerufen werden kann. Wo sie steckt (noch so gut versteckt), ist Minutensache, das herauszufinden. Schließlich ist WB ein OpenSource-Projekt und JEDER kann sich den Code runterladen und einfach mal nachschauen.

Die sicherste Lösung ist immer noch: Den Server gut pflegen und überwachen, damit der Interpreter gleich gar nicht erst ausfällt. Und DIESE Arbeit können wir weder dem Anwender noch dem Hoster abnehmen. Das fällt eindeutig unter die Rubrik "Eigenverantwortung"

Manuela

[evaki]

Wurde schon mehr als oft an mich herangetragen.
Wie machbar, auch wenn es zwangsläufig Core-Patches bedeutet?
Jedenfalls sollns dem Zugriff über http entzogen werden, also auch wenn der Server mal nur Text ausgibt, statt dem Interpreter was abzugeben 
Bei DirectoryIndex off gibt's Einsicht in temp, deshalb auch dort.
- also ab in den Keller.
MfG. Evaki