Linux - 4

Eingabedaten validieren sollte die erste Lektion für alle sein, die sich mit ihren Scripten ins "WeltWeite Warten" (www) trauen.

Leider gibt es immer wieder traurige Gegenbeispiele. fefe hat jetzt entdeckt, dass packages.debian.org die URL-Parameter ungeprüft übernimmt, inclusive der auf der Seite angezeigten MD5SUM des Pakets. Sowas ist ziemlich blauäugig ;-)

Vor ein paar Stunden konnte man noch beliebigen HTML-Code einschleußen (siehe Screenshot - ja, soviel Spaß muss sein), inzwischen wird "immerhin" die MD5SUM auf Länge und erlaubte Zeichen überprüft. Eine falsche MD5SUM ausgeben geht immer noch, solange die Länge stimmt.

Eine falsche MD5sum in Verbindung mit einem manipulierten FTP-Server heißt de facto, dass jemand ein gefaktes Paket mit beliebig bösem Inhalt anbieten kann und das nichtmal auffällt. Auf debian-www hält man sowas aber für "low risk". Es geht ja auch nur um potenziell gefakte Pakete mit bösen suid-root Programmen...

Was fefe übersehen hat: auch die anderen Parameter sind beliebig manipulierbar. Ich bin mal gespannt, wie lange Debian den Internet Explorer zum Download anbietet *eg*

Wie man sowas manipulationssicher programmiert? Eigentlich recht einfach - man packt die Nutzdaten (Paketnamen, MD5SUM usw.) in eine Datenbank und übergibt dem Script nur die ID als Parameter.

UPDATE: Inzwischen wurde die RegEx etwas verschärft und erlaubt nur noch [0-9a-f]. Ich habe die obigen Links etwas angepasst, damit sie weiterhin funktionieren. Falsche MD5SUMs kann man immer noch einschleußen...

Das ist die Mailstatistik dieses Servers der letzten Woche. Die großen Ausschäge in der "Rejected"-Kurve stammen im Wesentlichen aus "Relay access denied" von einer einzigen IP.

Falls jemand gern Rätsel löst, hätte ich ein paar Fragen:

• Wann ist ein neuer Kunde dazugekommen?
• Ist es ein Privat- oder ein Geschäftskunde?
• Wann hat er endlich geglaubt, dass er SMTP Auth aktivieren muss? ;-)

Anhand der Grafik sollte die Lösung recht leicht zu finden sein. *g*

UPDATE (11.12.2006): Wie sich inzwischen herausgestellt hat, hat die Firewall die SMTP-Authentifizierung rausgefiltert...

So, seit ein paar Tagen läuft openSUSE 10.2 beta2 auf meinem Laptop. Wie es bisher aussieht, gibt es wenig Grund zum Klagen.

Die schlimmsten Bugs, die ich entdeckt habe, sind zwei Probleme im Paketmanager. Der eine sorgt für einen Hänger, wenn eine (Online-)Installationsquelle nicht verfügbar ist (#221071), der andere für einen riesigen Stapel Fehlermeldungen, wenn eine Installationsquelle eine Apache-Fehlermeldung statt der Metadaten liefert (#218552). Als Workaround hilft es, nur funktionierende Installationsquellen zu verwenden ;-)

Falls sich jemand Sorgen um den Status des Paketmanagers macht: diesmal funktioniert er wirklich ;-) out of the box und muss nicht erst wie bei 10.1 zurechtgepatcht werden. Ach ja, und man kann zmd und zen-updater durch opensuse-watcher ersetzen, der direkt auf libzypp aufsetzt. Bleiben nur noch die kaputten Berechtigungen bei permissions.secure (#216485).

Der einzige Bug, der in der täglichen Arbeit nervt, ist ein hyperaktiver artsd, der den Prozessor unnötig beschäftigt (#178930) - naja, dafür gibt es killall -9...

Dazu kommen die üblichen Kleinigkeiten - ein paar verwirrende Schaltflächen (#218677), eine komische Übersetzung (#220668) oder auch ein fehlendes Leerzeichen (#220875).

Ach ja, das Syntax-Highlighting for AppArmor-Profile in vi funktioniert dank meiner Mithilfe wieder (#190084).

Am schönsten fand ich aber die Tipps beim KDE-Start (Screenshot rechts oben). Dort wird u. a. erklärt, dass KDE in viele Sprachen übersetzt ist - und genau dieser Text ist nicht übersetzt *g* (#221177 - hmmm, sollte ich den wegen Peinlichkeit zum Blocker machen?)

"404 not found" hat wohl jeder schon mal gesehen.

Zur Abwechslung biete ich "404 bugs found" ;-)

Ja, von SUSE Linux 9.2 beta bis heute hat sich einiges angesammelt. Darunter waren einige Dauerbrenner, z. B. der Dualhead-Betrieb auf meinem Laptop (#61858), der dem Blinker-Prinzip folgt (pro SUSE-Release: geht, geht nicht, geht, ...) und PHP open_basedir, das ich gern pro vHost setzen würde - dummerweise werden aber die Einstellungen der vHosts bunt durcheinandergemischt (#136651). Der letzte "Fix" vor einiger Zeit war leider wenig erfolgreich. Ich bin ja mal gespannt, ob der jetzt angekündigte Patch das Problem endlich behebt ;-)

Andere Bugs befassten sich mit Ausnahmesituationen (z. B. dass /var/lib ein Symlink ist ;-) - #181606) und wieder andere "nur" mit ungewohnten Tastenfolgen für Datei - Öffnen (#215576). Auch der Spaß kam nicht zu kurz, wie beispielsweise einige Kommentare in Bug #141107 oder Bug #180796 zeigen. Dazu kamen diverse Verbesserungsvorschläge, von denen manche sofort und manche nach deutlichem Nachhaken (#206414, #143648) umgesetzt wurden. Beim Betatest der 10.1 hatten insbesondere die Programmierer von YaST und der Paketverwaltung ihre Freude - in diesen Bereich fielen 64 meiner 152 Bugreports zur 10.1 (was mich nebenbei zum zweitaktivsten Bugreporter nach Andreas Jaeger (182 Bugreports) gemacht hat ;-)

Nicht nur die Programmierer, auch das Doku-Team hatte seinen Spaß mit mir (oder umgehehrt?), als ich im berühmt-berüchtigten Bug #65000 (#50000 zu Zeiten von bugs.suse.de; ich habe zwar trotz der runden Zahl nichts gewonnen, aber "lots of people here were annoyed by it - they wanted to file this magical number themselves ;))") diverse Fehler im Handbuch ("handbug?") der 9.2 berichtete. Jede Büroklammer im Handbuch markierte einen Fehler im Kapitel "Shell", das Foto ging vorab ans Doku-Team. Die erste Reaktion seitens Jana Jaeger auf meinen Bugreport war dann übrigens "@bugreporter: please do not ever touch a paperclip again ... :)"

Inzwischen helfe ich gelegentlich auch selbst bei der Fehlerbehebung, beispielsweise in pin und in apparmor.vim (vim Syntax-Highlighting für AppArmor-Profile).

Nur einen Bug konnte ich bis heute nicht beheben: der Tag hat leider nur 24 Stunden. Egal, nehme ich eben die Nacht dazu ;-)

Ach so: Die älteren Bugreports für SUSE <= 9.3 sind nur für alteingesessene Betatester zugänglich, daher sind nur rund 290 Bugs öffentlich sichtbar. Vermutlich erhöt sich die Zahl aber demnächst - ich will morgen openSUSE 10.2 beta1 installieren...

Ich habe seit einiger Zeit versucht, Pakete für courier-authlib-mysql in SUSE Linux integriert zu bekommen, nachdem diese des öfteren nachgefragt werden. Obwohl nur eine Änderung im Specfile erforderlich ist, endeten entsprechende Feature Requests bisher immer mit "wontfix".

Aber: Es geschehen noch Zeichen und Wunder ;-)

Auf dem kleinen Dienstweg (Mail an AJ) habe ich jetzt erreicht, dass es ab SUSE 10.2 (das dann übrigens openSUSE 10.2 heißt) ein courier-authlib-mysql Paket gibt - und nebenbei auch -pgsql und -pipe Pakete :-)

Übrigens: courier-authlib-mysql-Pakete für SUSE Linux 10.1 habe ich unter software.opensuse.org/download/home:/cboltz/ im Angebot - einzige Änderung zum Originalpaket der 10.1 ist die Aktivierung des -mysql-Pakets im Specfile.

Als Tastaturliebhaber muss ich bei dieser Initiative natürlich auch mitmachen ;-)

Der Server, auf dem auch dieses Blog liegt, hatte in der Vergangenheit öfter Schluckauf mit der Zeit:

• die Voreinstellung von 1&1 war "lokale Zeit", also ohne automatische Sommerzeitumstellung und grundsätzlich eine Stunde daneben
• auch nach der Umstellung auf UTC wollte sich die Uhr nicht automatisch auf Sommerzeit umstellen
• komischerweise hat ein Aufruf von yast2 timezone ohne irgendeine Änderung die Zeit immer korrigiert
• xntpd hat sich wegen einer Stunde "Zeitverschiebung" gleich nach dem Start verabschiedet

Nach längerer Zeit der Verwunderung habe ich endlich das Problem gefunden:

# rpm -V timezone
S.5....T   /usr/share/zoneinfo/Europe/Berlin

Nach Neuinstallation des timezone-Pakets bin ich die Zeitverschiebung endlich los.

Wer oder was die Datei überschrieben hat? Keine Ahnung - ich wäre aber nicht überrascht, wenn Plesk mal wieder seine Finger im Spiel gehabt hat.

(Hatte ich eigentlich schon erwähnt, was ich von Plesk halte? ;-)

Update: Zur Sicherheit sollte man auch noch die Zeitzone in den PHP-Scripten angeben:

<?php putenv( "TZ=Europe/Berlin" ); ?>

Novell hat ja mit der Entscheidung, keine non-GPL Kernelmodule mehr in SUSE Linux 10.1 mitzuliefern, für einigen Wirbel gesorgt.

Von den betroffenen Firmen war natürlich keiner begeistert (klar, die müssen jetzt die ganze Arbeit an den Treibern selbst machen). Andererseits sollen die neuen Kernel Module Packages ja Kernelupdates überleben und sind somit deutlich benutzerfreundlicher.

AVM tat sich besonders hervor und scheint derzeit Treiberpolitik auf dem Rücken der Benutzer zu machen.