Kleinigkeiten
Tom
- php
0 Kleinigkeiten Nachtrag
Tom0 Andreas Korthaus0 Tom0 Sven Rautenberg0 Tom0 Andreas Korthaus0 Tom0 Johannes Zeller0 Tom0 Johannes Zeller0 Tom
Hello,
beim Absichern von Seitenzugriffen sind mir ein paar Kleinigkeiten aufgefallen:
dirname($_SERVER['DOCUMENT_ROOT'])
schneidet das letzte Glied ab, wenn Document Root auf dem Server nicht mit abschließendem Slash eingetragen ist.
Ich gehe einfach mal davon aus, dass es beim Apachen richtig ist, die Verzeichnisse mit abschließendem Verzeichnistrenner anzugeben.
Jedenfalls kann man sich durch diese Unsauberkeiten eine Menge Ärger einfangen.
Währen readdir() _alle_ Einträge in der Veruzeichnistabelle liest, lässt glob() die .ht Dateien aus. Ist dieser Bug ein Feature? Kann man sich darauf verlassen, dass das immer so ist? Ich habs vielleicht überlesen, jedenfalls konnte ich nichts finden.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Hello,
dirname($_SERVER['DOCUMENT_ROOT'])
schneidet das letzte Glied ab, wenn Document Root auf dem Server nicht mit abschließendem Slash eingetragen ist.
Hoppala: in dieder PHP-Version schneidet Dirname() immer das letzte Glied ab! Das ist aber hässlich. Wenn man also ein "real_dirname()" haben will, dass dann zwangsweise auch die Existenz und Lesbarkeit im Filesystem testen muss, muss man sich also selber was schreiben.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Hallo Tom!
dirname($_SERVER['DOCUMENT_ROOT'])
DOCUMENT_ROOT ist per Definition ein Verzeichnis, ist somit sinnfrei sowas zu machen ;-)
schneidet das letzte Glied ab, wenn Document Root auf dem Server nicht mit abschließendem Slash eingetragen ist.
dirname() extrahiert das Verzeichnis gemäß POSIX-Standard aus einer vollständigen Pfadangabe.
Jedenfalls kann man sich durch diese Unsauberkeiten eine Menge Ärger einfangen.
dirname($_SERVER['DOCUMENT_ROOT']) ist unsauber, ja.
Währen readdir() _alle_ Einträge in der Veruzeichnistabelle liest, lässt glob() die .ht Dateien aus. Ist dieser Bug ein Feature? Kann man sich darauf verlassen, dass das immer so ist? Ich habs vielleicht überlesen, jedenfalls konnte ich nichts finden.
glob() durchsucht das Verzeichnis nach "Patterns", gemäß der libc Funktion glob(), siehe: http://www.gnu.org/software/libc/manual/html_node/Pattern-Matching.html#Pattern-Matching
Die Funktion soll kein vollständiges Verzeichnis listen wie z-B. scandir().
Grüße
Andreas
Hello,
Hallo Tom!
dirname($_SERVER['DOCUMENT_ROOT'])
DOCUMENT_ROOT ist per Definition ein Verzeichnis, ist somit sinnfrei sowas zu machen ;-)
Troll! Das ist doch nur ein Beispiel gewesen.
schneidet das letzte Glied ab, wenn Document Root auf dem Server nicht mit abschließendem Slash eingetragen ist.
dirname() extrahiert das Verzeichnis gemäß POSIX-Standard aus einer vollständigen Pfadangabe.
Wie lautet der POSIX-Standard dafür? Nuss ich doch glatt mal suchen...
Dirname ist also nicht geeignet, aus einer Angabe, von der ich nicht weiß, ob sie nur eine Datei, ein Verzeichnis oder einen vollständigen Pfad zur Datei enthält, das Verzeichnis zu bestimmen.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Moin!
Dirname ist also nicht geeignet, aus einer Angabe, von der ich nicht weiß, ob sie nur eine Datei, ein Verzeichnis oder einen vollständigen Pfad zur Datei enthält, das Verzeichnis zu bestimmen.
dirname() ist eine Stringfunktion, keine Dateisystemfunktion. Sie prüft nicht, ob das übergebene Argument real existiert und welchen Typ im Dateisystem es hat.
dirname('/irgendein/pfad/name') muß zwingend /irgendein/pfad ergeben, egal ob name nun ein Verzeichnis oder eine Datei ist, weil beide identisch gehandhabt werden - Verzeichnisse sind nur Dateien mit besonderem Inhalt.
Wenn du wissen willst, ob das Ziel der Pfadangabe irgendwas bestimmtes ist, solltest du mit den is_*-Funktionen arbeiten - das erfordert dann aber Zugriff aufs lokale Dateisystem - dirname() hingegen funktioniert mit allen möglichen Strings.
Hello,
dirname('/irgendein/pfad/name') muß zwingend /irgendein/pfad ergeben, egal ob name nun ein Verzeichnis oder eine Datei ist, weil beide identisch gehandhabt werden - Verzeichnisse sind nur Dateien mit besonderem Inhalt.
Wenn du wissen willst, ob das Ziel der Pfadangabe irgendwas bestimmtes ist, solltest du mit den is_*-Funktionen arbeiten - das erfordert dann aber Zugriff aufs lokale Dateisystem - dirname() hingegen funktioniert mit allen möglichen Strings.
Das sieht so aus.
Nun könnte aber dirname() so intelligent sein, und
dirname('/irgend/ein/anderer/pfad/') eben mit '/irgend/ein/anderer/pfad/' zu beantworten,
denn das kann eigentlich keine Datei sein.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Hallo Tom!
Nun könnte aber dirname() so intelligent sein, und
dirname('/irgend/ein/anderer/pfad/') eben mit '/irgend/ein/anderer/pfad/' zu beantworten,
denn das kann eigentlich keine Datei sein.
Prinzipiell hast Du Recht, das wäre eine Abweichung vom POSIX-Standard (der AFAIR besagt, dass ein Pfad, der auf "/" endet so behandelt werden soll als wäre zusätzlich ein "." angehängt), allerdings ist das für dirname() irrelevant, da die Funktion nur einen vollständige Pfad zu einer Datei verarbeiten soll:
"Given a string containing a path to a file, this function will return the name of the directory."
Da weder /irgend/ein/anderer/pfad/ noch /irgend/ein/anderer/pfad/. ein Pfad zu einer Datei ist, übergibst Du einen ungültigen Parameter.
Bisher kam ich damit auch eigentlich gut aus. Hast Du denn ein (sinnvolles) Beispiel wo dies ein Problem darstellt?
Grüße
Andreas
Hello,
Bisher kam ich damit auch eigentlich gut aus. Hast Du denn ein (sinnvolles) Beispiel wo dies ein Problem darstellt?
Nicht wirklich, da ich keinen "offenen Lösungen" präferiere.
Aber für die Freunde von "include()" dürfte das an einigen Stellen ein echtes Problem sein.
Ich habe selber auch _eine_ Stelle im CMS, die davon betroffen ist, aber die will ich gewiss nicht offenbaren, bevor ich das Problem fixed habe.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Hallo Tom,
Aber für die Freunde von "include()" dürfte das an einigen Stellen ein echtes Problem sein.
Wieso? Kannst du da vielleicht ein Beispiel geben?
Schöne Grüße,
Johannes
Hello,
Aber für die Freunde von "include()" dürfte das an einigen Stellen ein echtes Problem sein.
Wieso? Kannst du da vielleicht ein Beispiel geben?
Ja, wenn ich mal Zeit habe, das vernünftig auszuarbeiten, sogar ausführlich.
Jetzt an dieser Stelle nur der Hinweis darauf, dass es viele "CMS" gibt, die über eine Paramter in der URi direkt das include() refernzieren, dass aufgerufen werden soll. Da ist es i.d.R. notwendig, dass man Pfad und Dateinamen sauber voneinander trennt. Ich habe da leider auch selber einen fall, bei dem der _Pfad_ Relevanz hat. Das will ich aber eben selber erstmal reparieren, bevor ich es veröffentliche.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Hallo Tom,
Jetzt an dieser Stelle nur der Hinweis darauf, dass es viele "CMS" gibt, die über eine Paramter in der URi direkt das include() refernzieren, dass aufgerufen werden soll.
Meinst du das was ich denke? Wenn ja, dann hat das Programm noch ganz andere Probleme... Es ist ein Scheunentor für böswillige Zeitgenossen, wenn man URL-Parameter als Argument für include-verwendet.
Schöne Grüße,
Johannes
Hello,
Meinst du das was ich denke? Wenn ja, dann hat das Programm noch ganz andere Probleme... Es ist ein Scheunentor für böswillige Zeitgenossen, wenn man URL-Parameter als Argument für include-verwendet.
Wahrscheinlich schon.
Einige haben dann mit den Funktionen dirnname() und basename() schon mal "relative Sicherheit" geschaffen. Die funktioniert natürlich nur, wenn die Funktionen auch _immer_ wie erwartet funktionieren. Deshalb oben meine Frage zu glob(). Unterbindet das _immer_ die .ht-Dateien und -Verzeichnisse?
Harzliche Grüße aus http://www.annerschbarrich.de
Tom