Wenn ein Tool - wie z.B. PEAR - auf eine starre Verzeichnismimik angewiesen ist, darf es diese nicht konfigurierbar machen, ansonsten kann man das Tool in eine Struktur nach gutdünken implementieren.
PEAR ist aber ja nun mal geschaffen worden, um eine einheitliche und allseitig kompatible Entwicklung zu ermöglichen... und ausserdem kein "Tool", sondern eine Objektbibliothek, deren Module aufeinander aufsetzen!
Was zum Beispiel, wenn ich mein Contenido um Module erweitern möchte, die andere PEAR-Klassen benutzen, als die (paar) mitgelieferten
Wenn ich z.B. das SOAP-Paket nutzen möchten, benötigt dies die ordentliche Dateistruktur des PEAR-Frameworks, d.h. Node.php in XML/Tree/, usw.
Zur Sicherheit:
PEAR sollte ohnehin im include_path des Servers liegen, da sonst gar nichts geht! Wenn ich also (als Angreifer) auf eine PEAR-Klasse zugreifen möchte, brauche ich die Klasse nur einzubinden. wenn ich das machen kann, brauche ich Zugriffsberechtigungen für ausführbare Dateien auf dem Server. Wenn ich diese Rechte habe, ist zum Hacken der Seite PEAR nun wirklich nicht mehr relevant - ich kann ja eh machen, was ich will...
Im Übrigen sollte das PEAR-Verzeichnis ohnehin nicht öffentlich zugänglich sein, d.h. ausserhalb des DOCUMENT_ROOT liegen!
Wem die mit Contenido ausgelieferten Strukturen nicht passen, kann sie ja wieder auf das Original zurückdrehen.
Und dann? Contenido umschreiben und sämtlich Pfade umschreiben? Vielen Dank für die Arbeitserleichterung...!
Fazit: Sicherheitsprobleme auf Webserver entstehen bestimmt nicht durch eine einheitliche Verzeichnisstruktur von PEAR! Wenn man eine Software auf einem solchen Framework aufsetzen will, sollte man zur Vereinheitlichung der Schnittstelle auch das Framework nutzen, und sich nicht irgenwas zusammenbasteln und das unter dem Original-Namen verbreiten.
Gefunden -SORRY für den Einwand...