Inetd für ds26 >= 14.4

Das mit der BSS ist ein guter Punkt. Ich hab die Busybox in meinem Patch entsprechend angepasst (siehe Post #1). Dadurch ist die BSS nur mehr 180 Byte.

So, die vorläufig 'Komplettlösung' von mir ist jetzt fertig. Siehe Post #1.

Wie zwischenzeitlich schon erwähnt, wäre eine sinnvolle Konsequenz aus der Nutzung des inetd, auch das AVM-WebIf über selbigen laufen zu lassen, zumal der websrv im Normalbetrieb schon einiges an Speicher belegt; in meinem Fall laut 'top' immerhin 5,6%.

Leider hat websrv wohl wie gesagt keinen inetd-Modus. Soweit ich bisher herausfinden konnte, macht websrv an sich aber auch gar nichts spezielles; sämtliche Anfragen werden über webcm abgewickelt. Es sollte daher prinzipiell möglich sein, websrv komplett zu entfernen und durch einen anderen httpd zu ersetzen.

Als erste Idee kommt einem natürlich der Busybox-Httpd, den wir ja sowieso schon an Bord haben. Leider funktioniert bei diesem das Zusammenspiel zwischen httpd und webcm nicht korrekt; die Webseiten laufen nicht. Ausprobieren kann das jeder leicht selbst: einfach mal den httpd mit starten und dann auf entsprechend auf Port 82 ausprobieren. Meine Vermutung ist jetzt, dass evtl. irgend etwas am Environment der CGI-Scripte dem webcm fehlt. In einem Test habe ich mal verschiedene der von websrv gesetzten Variablen mittels eines Wrapper-Scripts an webcm übergeben, aber leider auch erfolglos.

Ich habe dann mal testweise den thttpd-Server für die Fbox gebaut, und siehe da, dort läuft das AVM-WebIf auf den ersten Blick ohne Probleme.

Vielleicht hat ja jemand eine Idee, woran es mit dem busybox-httpd noch haken könnte.

Gruss, Nico

Hallo,

ich wollte eigentlich erst posten, wenn das die Lösung spruchreif ist, aber bevor sich jetzt alle den Kopf zerbrechen mal kurz eine Zwischeninfo:

Olistudent hat herausgefunden, dass es nicht an den Umgebungsvariablen liegt, sondern an der Art des Aufrufs. Alle Webserver wechseln zur Ausführung eines CGIs in das Verzeichnis, in dem selbiges liegt. Der busybox-httpd ermittelt aber den kompletten Pfad zum CGI mittels realpath() und expandiert daher auch eventuelle Symlinks (wie in diesem Fall den von /usr/www/html/cgi-bin/webcm auf /usr/www/cgi-bin/webcm). Er wechselt daher nicht in den Pfad, wo der Symlink liegt, sondern eben in den, wo die tatsächliche Datei liegt. Im weiteren Verlauf findet das CGI dann natürlich seine Dateien nicht mehr, die ja relativ angegeben werden.

Schnellfix: Durch Kopieren des Binaries lässt sich das Problem beheben und das WebIf läuft.

Zum Test könnte man jetzt auch einen Wrapper schreiben, der das CGI wieder ins richtige Verzeichnis chdir()ed.

Da die anderen Webserver dieses Verhalten jedoch nicht zeigen, denke ich, die 'richtige' Lösung für das Problem ist ein Fix des Busybox-Httpd. Ich habe sowas schon fertig und werde es gleich mal testen, dann gibts mehr Infos.

Gruss, Nico

Ich dachte nicht, dass es so schnell geht . Also, mit dem modifizierten Busybox-Httpd läuft das WebIf jetzt augenscheinlich, und zwar sowohl im Standalone-Modus als auch über inetd.

Einstellungen ändern ist kein Problem, aber ich habe jetzt noch keine komplizierteren Sachen wie ein Firmware-Update ausprobiert. Letzteres ist bestimmt noch etwas frickelig, das probier ich später mal aus.

Den BB-Patch habe ich mal angehängt. Die Funktion abspath() habe ich selbst geschrieben, mich dabei aber an vorhandenem orientiert. Bin schon sehr verwundert, dass sowas nicht in der libc drin ist - jede GNU-Software implementiert das selbst (gcc, make, emacs,...).

Edit: Ach ja, nein, in BB 1.5.1 ist die Situation noch die gleiche. Ist wohl nicht so häufig und auch ein Sicherheitsrisiko, mit Symlinks und CGIs rumzuhantieren (vor allem wenn potentiell nicht vertrauenswürdige Personen CGIs erstellen können bzw. Schreibzugriff auf die Webserver-Verzeichnisse haben). Aber das ist eine komplett andere Baustelle, denn momentan wird dem Symlink ja auch gefolgt, nur die Aufrufumgebung stimmt dann nicht mehr.

Gruss, Nico

Hm. Nein. xgetcwd() gibt ja nur das aktuelle working directory her.

Der busybox-httpd hat bisher den Pfad zum cgi (also bspws. den Teil der Url: "/cgi-bin/webcm") genommen, das leading / entfernt, und dann realpath() damit aufgerufen. realpath() fügt jetzt diesen Pfad an das cwd an, expandiert ihn (er kann z.B. ./ oder ../ enthalten), und löst dabei auch sämtliche enthaltenen Symlinks auf.

Der so erhaltene Pfad wird dann weiterverarbeitet (z.B. in die Env-Variable SCRIPT_FILENAME) und es wird in das Verzeichnis der in diesem Pfad bezeichneten Datei gewechselt. Diese Verhalten ist insofern falsch, als dass der httpd als Userspace-Anwendung sich um die FS-Spezifika wie Symlinks nicht kümmern sollte, sondern die Symlinks wie jede andere Datei auch behandeln sollte.

Was der httpd also braucht, ist eine Funktion abspath(), die das gleiche macht, wie realpath(), dabei aber eben die Symlinks *nicht* verfolgt. Und genau das macht meine Funktion. Wie gesagt, gcc und make haben z.B. auch solche Implementierungen. Die sind aber um einiges komplexer, da sie auch noch verschiedene OS-Spezialitäten berücksichtigen, was wir natürlich nicht müssen.

Gruss, Nico

kriegaex:
Ja, aber es macht doch was ganz anders? Es gibt mir das aktuelle Verzeichnis (also das, in dem der momentan ausgeführte Kontext läuft). Während die Funktionen realpath() und abspath() mir den absoluten Pfad zu einem übergebenen, potentiell (und in diesem Fall wohl immer) relativen Dateinamen gibt.

RalfFriedl:
Im Prinzip ist das richtig, das angesprochene Problem ist nur das Wechseln in das korrekte Verzeichnis. Daran hängt aber auch, dass die CGI-Umgebung korrekt initialisiert werden muss, und der BB-Httpd stellt da z.B. eine Variable SCRIPT_FILENAME zur Verfügung, die den kompletten Pfad zum CGI enthält. Dort wird halt momentan der realpath() eingetragen. Damit das Verhalten konsistent bleibt, muss der abspath() da hin.

Man könnte das natürlich weglassen, aber man weiss ja nicht, welche Scripts sich auf solche Besonderheiten verlassen (denn SCRIPT_FILENAME gehört wohl nicht zur CGI 1.1-Spezifikation).

Gruss, Nico

RalfFriedl schrieb:

Das Verzeichnis, in dem sich das Script befindet, ist doch anscheinend das, was erwartet wird, und sollte daher funktionieren, ob es sich dabei um die Datei selbst oder einen Link handelt.

Zum Vergrößern anklicken....

Genau. Ist ja auch offenbar der Fall.

RalfFriedl schrieb:

chdir (dirname (WWWROOT + SCRIPT_NAME))
Die einzige Frage ist also, ob das CGI-Programm in SCRIPT_FILENAME seinen eigenen realpath braucht. Ich gehe davon aus, daß dies nicht der Fall ist.

Zum Vergrößern anklicken....

Wir brauchen von Deinen Vorschlägen diesen. Was genau ein Script in SCRIPT_FILENAME erwartet, kann ich nicht sagen. Aus meiner Sicht wäre realpath() (also mit Auflösung von Symlinks) aber nicht korrekt, da Symlinks aus Anwendungssicht wie normale Dateien behandelt werden sollten. Und saubererweise schreibt man in solch eine Variable in meinen Augen eben einen absoluten Pfad, ohne eventuelle ../ oder ähnliches. Sonst könnte der BB-Httpd sich das realpath() auch direkt sparen. Deswegen sehe ich die Lösung mit (meinem|einem anderen) abspath() immer noch als die optimale an. Man könnte das aber auch die Upstream-BB-Autoren entscheiden lassen.

Gruss, Nico

Ich habe das jetzt nicht ausprobiert, aber der Patch sollte genau so funktionieren. Wir brauchen ja nur eine Hand voll Zeilen aus dem ganzen Patch.