Achtung: Dieses Blog ist umgezogen auf die Adresse blog.xwolf.de
Bitte ändern Sie Ihre Bookmarks entsprechend.

Montag, 25. Oktober 2004
Wie lange dauert das Löschen von 15442 Mails über IMAP?
Katastrophen und Probleme
Ich hab wiedermal vergessen, meine SPAM-Folder rechtzeitig zu löschen...

... link


Lästern über PHP - Teil 2
Kommentar
Zu meinem vorherigen Lästern zu PHP passt folgender Artikel auf den sunflyer aufmerksam macht: PHP's safe_mode or how not to implement security.

Ein Satz daraus, den ich nur unterstreichen kann:

Perhaps, my biggest pet peeve pertaining to safe_mode is that it is not really safe, merely offering an illusion of safety that does not stand to closer examination. A creative attacker will be able to easily to bypass it.

Wobei ich das creative attacker doch noch abschwächen würde. Eigentlich sollte jeder, der sich etwas mit Filerechten und Multiuser-Systemen auskennt, leicht in der Lage sein, die Sicherheitslücken zu finden und auszunutzen.


Am Ende des Artikel gibt der Autor einige Lösungsmöglichkeiten vor.
Meine wäre diese:

1. PHP wird mit Safe_Mode = On konfiguriert, aber gleichzeitig auch mit open_basedir.

2. Der Zugriff auf die Verzeichnisse eines virtuellen Hosts wird beschränkt auf den User, seine Group und den Apache-Server. Andere User, die Zugriff auf das Filesystem haben, erhalten kein Zugriff. Bei einem Mass Hosting Provider wird es hier zwar Probleme geben, wenn man einfache Unix-Groups nutzt, jedoch läßt sich dies über dynamisch zugeordnete NIS-Maps lösen.

3. Der Zugriff wird nicht allein mittels CHMOD 755 gelöst, was ja "others" reinlassen würde oder mit CHMOD 750 (sinnlos, wenn der User in gruppe web ist- weil andere User wären da ja auch drin - also kein Schutz gegen die anderen User), sondern mit ACLs:
Der Benutzer einer Domain erhält beispielsweise eine Kennung
kuAB00wm
und eine Gruppe
kuABwm

Sein DOCUMENT-Root-Verzeichnis erhält dann
chown kuAB00wm:kuABwm DIR
und
chmod 750 DIR

Damit der Webserver-User www reinkann wurd ein ACL gesetzt:
setfacl -m user:kuAB00wm:rwx,user:www:r-x,mask:rwx DIR


Folge: In das Verzeichnis kommt der User, etwaige Kollegen, die in der selben Gruppe sind und der Webuser.
Andere User auf dem Filesystem kommen nicht rein.


Unabhängig von diesen Lösungen sollte jedoch der 4. teil der Lösung trotzdem nicht vergessen werden:

4. PHP wird als CGI ausgeführt.


Wenn aber PHP als CGI ausgeführt wird und PHP 5 genommen wird, wo ist dann noch der Unterschied zu Perl ?
(Oder genauer gesagt zu Perl mit mod_eperl - damit kann man den Perlcode auch in HTML-Files einbetten.)

... link


PR-Realitätsverschiebung in Sachen PHP
Kommentar
Die PHP-Leute machen seit jeher gute PR für ihre Sprache.
Auch wenn mit der neuen Version von der Codestruktur kaum noch grosse Unterschied zu Perl da sind (es hat sich stetig dem Stand von Perl 5 angenähert und hat, wenn man an Perl4 zurückdenkt, eine ähnliche Feature-Historie), wird dort jetzt noch behauptet der Code von Perl sei komplex, der von PHP dagegen leicht...

Nun ja, aber diese "Meldung" ist ja wohl die Krönung der Realitätsverschiebung:

Student Suspended Over Suspected Use of PHP

Darin wird erst ne nette Geschihcte von irgendwelche dummen Lehrern und Eltern erzählt, die PHP mit Drogen verwechseln.
Wobei dann am Ende dann so eine Erklärung kommt:

PHP is a hypertext preprocessor, which sounds very dangerous. It is believed that many users started by using Perl and moved on to the more powerful PHP. For more information on how to recognize if your child may be using PHP please visit http://www.php.net.

Eigentlich ist das Gegenteil der Fall.
PHP wird hauptsächlich von den Newbies verwendet, die damit ihre ersten Skriptchen starten.
Das ist auch ganz gut so. Wenn ich an die ganzen DAU-Fragen dachte, die in den letzten Jahren bei den Perlforen reinkamen, dann bin ich direkt froh darüber.
Wenn man jedoch mehr als nur irgendwelche Formulareingaben verwalten will, dann kommt man nicht drumherum, auch auf dem Filesystem selbst zu arbeiten und auf diesen Programme auszuführen.
Ebenso werden Sicherheitsaspekte immer wichtiger. Heute vergeht kein Tag mehr, wo auf Bugtrag nicht ein halbes Dutzend an PHP-Skript-Sicherheitsbugs gemeldet werden.
Die lasche Haltung in Bezug auf sichere Transaktionen, Variablenüberprüfungen, Multiuser-Konzepte (sowohl auf dem Server als auch über Web), die bei vielen PHP-Programmen zutage tritt ist mehr als deutlich.
Sicher: Mit jeder Programmiersprache kann man Mist machen. Aber man muß sagen, daß durch die Art, wie bei PHP dies Thema behandelt, nämlich wie sehr dies als unwichtig erachtet wird, daß hierdruch die Zahl der unischeren Skripts noch mehr steigt.

Lange Rede, kurzer Sinn: PHP ist das GW-Basic von heute. Und genausowenig wie GW-Basic mächtiger als C war, ist PHP mächtiger als Perl.

Es ist anders.
Die Mächtigkeit einer Programmiersprache ergibt sich IMHO ohnehin zu 75% daraus, was der Programmierer damit zaubern kann.

... link


Spamfutter

Die folgenden E-Mail-Adressen dienen lediglich dazu, SPAM-Bots dazu zu verleiten, ungueltige Adressen in die SPAMer-Datenbanken zu schreiben. Bitte ignorieren.

dmqrs@iueuogcgkipb.com, cesydduk@bebkbdubvmqqqaa.it, dgjjeuvon@wdvvybcqekdp.jp, cksu@ybhwvwnjnjfjkyp.ch, dnfhqjc@bnkhokzuxzhrwyosplvlupch.de, bwmb@mdssdsrsjsuefoatbwq.biz, iiyao@xseypglhaczfqstxrpu.es, vbodj@nnxbmwdmiakkthgjgekkhg.com, kcnxuvsnyl@ieejiqwml.de, uoopcvo@msrnlbpvdmjx.br, ijervggvq@knibjuwip.pl, ynm@kjwjsowsp.de, enquvfngfn@cgnwonopdeeepwonjqepn.ca, eshgmxzk@htfvhbzsbmkwtshot.fr, rlnx@wyojgfxmctvlmm.tv, jxkyuhxiw@sinripdrckbazk.dk, buukh@xuebpukhnvwdshbzvhf.fr, llww@dnyqhzrbmwdobucpmmjgjw.com, uxg@jubnrrjmbsawzfxluvumuxj.nl, emfqqtvp@eqjyxpuwnlrxjvemsbpeue.ca, tdxi@mtircfbkdekyxqlmqcajw.jp, ochrhfcc@lffejybqqwggxymw.biz, bnzl@rsqepmwhvvlqc.fr, ribpseux@bujbceumgqdhofukcbviwepb.us, ejv@nfsuhzmzbhfrytdtnp.it, hnngkjjey@vgegshrkbzdbxgejlw.tv, sfnb@ilfpfragimrsqimuvtxpqbc.es, qcq@hqxaprxqescf.org, skqomd@eaplvubjpcpdl.eu, wjrho@cnggjfmzu.br