[Frage] lighttpd: Wie kann man bei aktiviertem chroot Bash-Befehle in cgi-Dateien nutzen?

[FischersFreetz]

Hallo,

ich habe auf einer 7590 die Bash-Shell (statisch gelinkt) und den lighttpd-Webserver via FREETZ erfolgreich installiert. Das Anzeigen einfacher HTML-Seiten gelingt auch problemlos.
Nun möchte ich mit Hilfe von Bash-Befehlen Internet-Seiten dynamisch gestalten können. Und dabei eröffnen sich mir - mein geringes Vorwissen sei an dieser Stelle erwähnt - einige Fragen:

[1] Wie geht man dieses Vorhaben eigentlich grundlegend und effizient an? (* php, haserl, bash (pur), .., ??? *)

Meine bisherigen Gedanken und ersten Versuche gingen dahin, die Ausgaben eines Bash-Scriptes anzeigen zu lassen:

#!/usr/bin/bash --shell=/usr/bin/bash
echo -e "Content-type: text/html\r\n\r\n"
datum=$(date)
echo -e "[Hallo Bash] - [$0] - [$datum]"

Dazu erweiterte ich die lighthttpd.conf um

server.modules += ( "mod_cgi" )
cgi.assign = ( ".cgi"  => "/usr/bin/bash" )

kopierte die "/bin/bash" nach ".../lighthttpd/www/websites" und erreichte so folgende Anzeige

[Hallo Bash] - [/websites/index.cgi] - [ ]

[2] Warum wird hier $datum nicht angezeigt? bzw.

[3] Wie kriege ich die bash vollfunktionsfähig in die chroot-Umgebung des Webservers?
(Und Ist diese Frage eine logische Schlussfolgerung aus [2]?)

Für Hinweise und Gedanken wäre ich dankbar.

FischersFreetz

 

[koyaanisqatsi]

Moinsen


Naja, Shellscript und die vielen kleinen Gizmos im PATH ist jeder anderen Interpretersprache überlegen, schon Geschwindigkeitsmässig und mit Ressourcen fange ich besser gar nicht mit an , meine Meinung.

Nun, eine CGI hat auch ihr eigenes Environment.
Was gibt denn...

#!/usr/bin/bash
echo 'content-type: text/html

'
echo -n "<pre>$(env)</pre>"

...aus?
PATH in Ordnung?
Zuviel des Guten im Environment?*
"env -i" ist dein Freund.


Tipp: Zuweisungen besser vor der Headerausgabe platzieren...

#!/usr/bin/bash --shell=/usr/bin/bash
datum=$(date)
echo -e "Content-type: text/plain\r\n\r\n"
echo -e "[Hallo Bash] - [${0}] - [${datum}]"

...dann kann eine Variable schon in der Headerzuweisung genutzt werden.
Für Refresh: zum Beispiel ( Zeit und URL ).
...und die geschweiften Klammern für Variablen erhöhen die Identifizierbarkeit.


* Beispiel, so sparsam ist ein Apache 2 auf Linux

HTTP_ACCEPT_ENCODING=gzip, deflate, br
SERVER_NAME=[::1]
SCRIPT_NAME=/cgi-bin/env.cgi
HTTP_PRAGMA=no-cache
GATEWAY_INTERFACE=CGI/1.1
SERVER_SOFTWARE=Apache/2.4.38 (Debian)
DOCUMENT_ROOT=/var/www/html
HTTP_UPGRADE_INSECURE_REQUESTS=1
PWD=/usr/lib/cgi-bin
REQUEST_URI=/cgi-bin/env.cgi
SERVER_SIGNATURE=Apache/2.4.38 (Debian) Server at ::1 Port 80

REQUEST_SCHEME=http
QUERY_STRING=
HTTP_ACCEPT_LANGUAGE=en-US,en;q=0.9
CONTEXT_DOCUMENT_ROOT=/usr/lib/cgi-bin/
HTTP_ACCEPT=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
REMOTE_PORT=49454
SERVER_ADMIN=webmaster@localhost
HTTP_HOST=[::1]
HTTP_SEC_FETCH_USER=?1
HTTP_SEC_FETCH_SITE=none
HTTP_CONNECTION=keep-alive
SERVER_ADDR=::1
HTTP_DNT=1
HTTP_USER_AGENT=Mozilla/5.0 (X11; Linux i686 (x86_64)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.87 Safari/537.36
CONTEXT_PREFIX=/cgi-bin/
SHLVL=0
HTTP_SEC_FETCH_MODE=navigate
SERVER_PROTOCOL=HTTP/1.1
SERVER_PORT=80
SCRIPT_FILENAME=/usr/lib/cgi-bin/env.cgi
REMOTE_ADDR=::1
HTTP_CACHE_CONTROL=no-cache
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
REQUEST_METHOD=GET
_=/usr/bin/env

 

[FischersFreetz]

Hallo... und Danke für deine Reaktion auf meine Fragen.

Naja, Shellscript und die vielen kleinen Gizmos im PATH ist jeder anderen Interpretersprache überlegen, schon Geschwindigkeitsmässig und ...

Ist das so? Oder (nur) deine Meinung?

#!/usr/bin/bash
echo 'content-type: text/html'
echo -n "<pre>$(env)</pre>"

gibt folgendes aus:

content-type: text/html
<pre></pre>

Das Entscheidende fehlt.
EDIT. Und...

#!/usr/bin/bash
datum=$(date)
echo "Content-type: text/html"
echo "[Hallo Bash] - [$0] - [$datum]"
echo "env: <pre>$(env)</pre>"
echo "PATH: [$PATH]"
echo "SHELL: [$SHELL]"
ls
echo "ls errorcode: [$?]"

ergibt...

Content-type: text/html
[Hallo Bash] - [/websites/index.cgi] - []
env: <pre></pre>
PATH: [/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.]
SHELL: [/bin/sh]
ls errorcode: [127]

Ich überblicke noch nicht, in welcher "Umgebung" das Script arbeitet. ?
Und wie erzeugt man die passende Umgebung?

* Beispiel, so sparsam ist ein Apache 2 auf Linux ...

Was meinst du mit "sparsam"? Und was soll mir das sagen?

 

[PeterPawn]

Ich würde schon bei der Frage beginnen, was das für ein merkwürdiges SheBang in der ersten Zeile sein soll? Welche Version einer "bash" unterstützt denn eine (long-)Option "--shell=<something>"? Ich finde im Internet keine Stelle, wo Du das falsch abgeschrieben haben könntest.

Der Zweck und das Format eines SheBang ist z.B. hier erläutert: https://wiki.ubuntuusers.de/Shebang_für_Shellskripte/

Mit diesen Kenntnissen gewappnet, würde ich auch die "cgi.assign"-Zeile anders formulieren ... daß es sich um ein CGI-Skript handelt, wird bereits anhand des Pfades, unter dem es gespeichert ist, klar. Hier könnte (nein: sollte) man also ".sh" als "Erweiterung" verwenden (oder meinetwegen auch ".bash") und nur diese dann auf "bash" mappen.

Und in ein "chroot jail" kriegt man eben genau das hinein, was man (vorher) dort untergebracht hat. Wie der Name "change root" ja schon sagt (und auch die man-Page ist da derselben Ansicht), ändert man damit das "root"-Verzeichnis für einen Prozess. Man muß also nur dafür sorgen, daß da alles das enthalten ist, was der aufgerufene Prozess später mal benötigen könnte - das startet dann bei der "bash" als Interpreter für CGI-Skripte und geht bis zu den Kommandos, die von dieser "bash"-Instanz verwendet werden sollen (hier bei Dir betrifft es im Moment die Kommandos "date" und "env").

Die "bash" unterscheidet eben zwischen "builtins" (das sind die Kommandos, die sie bereits selbst kennt) und "external commands" (dazu gehören auch "date" und "env" - am besten liest man auch hier mal die "man page" zur "bash", das sind bei mir nur 3219 Zeilen) - wenn letztere nicht anhand des Suchpfads gefunden werden (wobei auch bei einer leeren PATH-Variablen normalerweise ein paar Verzeichnisse durchsucht werden: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html), kann die Shell sie auch nicht ausführen. Wenn Du hier (z.B. mit einem exec 2>&1) auch noch STDERR in Deine Ausgabe umleitest (man kann ja auch erst mal "text/plain" verwenden und muß nicht sofort HTML generieren wollen), dann siehst Du auch die Probleme, die Dein Skript noch so hat.

Du müßtest also unterhalb des Verzeichnisses, was Du als "chroot"-Basis verwenden willst, alles andere schon vor dem Start des HTTP-Servers so einrichten, daß da die (i.d.R. notwendigen) Verzeichnisse nach LSB (https://de.wikipedia.org/wiki/Linux_Standard_Base) existieren und in diesen Verzeichnissen all die Kommandos existieren, die später von den CGI-Skripten benötigt werden ... natürlich inkl. der Bibliotheken und allem Pipapo. Da ist es i.d.R. am einfachsten, man linkt sich die "echten" Verzeichnisse einfach in sein Jail bzw. man verzichtet (wenn man nicht gerade eine Site betreibt, wo die Hacker Schlange stehen bei ihren Angriffsversuchen) einfach erst mal auf "chroot", bis die Site "fertig" ist und man sicher weiß, wie man das Jail aufbauen soll und was da alles drin sein muß.

Schon die Frage, warum es nun unbedingt die "bash" sein soll und warum die "ash" der bereits existierenden BusyBox da nicht ausreicht, würde so manchem sicherlich Kopfzerbrechen bereiten ... und auch die Verwendung von "echo -e" würde man (ich) bei jemandem, der Shell nicht als "tägliches Brot" verwendet, nicht wirklich empfehlen.

Zwar funktioniert das unter "bash" oder "ash" oder "dash" (usw.) tatsächlich in den allermeisten Fällen, aber bei FreeBSD (oder generell bei BSD-Derivaten und damit auch bei MacOS X) scheitert man damit schnell mal: https://www.freebsd.org/cgi/man.cgi?query=echo und zum Funktionsumfang nach POSIX-Spezifikation gehört letztlich gar keine Option: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html ... aber hier macht es ein "printf" ebenso und das funktioniert dann (wenn man sich an den POSIX-Standard hält) auch überall in derselben Art und Weise und man hat etwas gelernt, was man praktisch ÜBERALL verwenden kann.

Zwar kann man auch "echo" benutzen (und alte Haudegen schwören darauf, weil es zu ihrer Zeit meist noch gar kein "printf" gab - siehe die Bemerkungen in der POSIX-Spezifikation) - aber wer es gleich mit "printf" lernt (was automatisch "cooked" arbeitet und die Escape-Sequenzen verarbeitet), der benutzt dann eben auch später weiterhin "printf" (oder er muß dann erst wieder mühsam "umlernen" und ich kann aus eigener, leidvoller Erfahrung berichten, daß das "ein Prozess" ist) und ist damit auf der sicheren Seite.

Die Frage, wie PATH tatsächlich aussieht, kannst Du also nicht mit einem $(env) klären, sondern da bietet sich ein printf "PATH=%s\n" "$PATH" eher an. Ein gänzlich leeres Environment wäre für ein CGI-Skript (oder -Programm) aber auch gänzlich untypisch - da sind wenigstens die Variablen enthalten, die dem Skript Auskunft über die Natur des Requests geben (woher kam er, HTTP oder HTTPS, aufgerufene URL, Servername, Portnummer, etc.) und wenn auch die - angeblich - nicht vorhanden sind, ist es Zeit, die "Anzeige" zu hinterfragen und erst einmal sicherzustellen, daß diese auch funktioniert.

==========================================================================

Aber gehe ich recht in der Annahme, daß Du hier:

den lighttpd-Webserver via FREETZ erfolgreich installiert.

wieder Freetz und Freetz-NG durcheinander geworfen hast? Wenn ja, vergiß alles, was ich geschrieben habe - von Freetz-NG habe ich keine Ahnung.

==========================================================================

EDIT: Eins noch ... wenn Du - wie weiter oben vorgeschlagen - die Ausgabe von STDERR auf STDOUT legst, kannst Du auch ein "-x" noch ins SheBang schreiben (diese Option gibt es dann wirklich) und Du erhältst ein wunderschönes Protokoll all dessen, was Dein Skript da so veranstaltet. Das wäre mein empfohlener Weg (zusammen mit der Ausgabe als "text/plain", bis die Kommandos komplett sind und funktionieren) für die "Programmierung" von CGI-Skripten mit einer Shell. Erst danach kann man dann auf "text/html" umstellen und sich ansehen, was der Browser aus der HTML-Ausgabe macht. Selbst wenn man darin dann noch Fehler hat und irgendwelche Ausgaben des Skripts ändern muß, sollte sich "am Rahmen" bzw. an den ausgeführten Kommandos dadurch nichts mehr ändern.

 

[koyaanisqatsi]

Was meinst du mit "sparsam"?

Naja, ich hatte mal einen Webserver in Freetz, der hat auch das Passwort im Environment, für das Freetz-Login.
...bis...

[Gelöst] - freetz-trunk httpd (über das freetz-WebIf) hält ungewollte Umgebungvariablen

env -i:lamer: Hab ich doch glatt gemacht,start_ch () { if [ -f /var/lock/$SERVICE ]; then echo $SERVICE" ist an" else # SERVICE starten statuslog $DAEMON_FULL":" $SERVICE" wird gestartet" "1" env -i "PATH=/bin"...

www.ip-phone-forum.de

@PeterPawn
Ja, printf nutze ich am liebsten in CGI Sourcecode.

printf("%s\n","Content-Type: text/html; Charset=UTF-8");
printf("%s%s%s\n","Set-Cookie: bgColor=",bgcolor,"; Max-Age=1200; Path=/");
printf("%s%s%s\n","Set-Cookie: txtColor=",txtcolor,"; Max-Age=1200; Path=/");
printf("%s%s%s\n","Set-Cookie: uName=",uname,"; Max-Age=1200; Path=/");
printf("%s%s%s\n","Set-Cookie: pWord=",pword,"; Max-Age=1200; Path=/");
printf("%s%s%s\n","Set-Cookie: fBox=",fbox,"; Max-Age=1200; Path=/");
printf("%s%s%s\n","Set-Cookie: fBook=",fbook,"; Max-Age=1200; Path=/");
printf("%s%s%s\n","Set-Cookie: dwl=",dwl,"; Max-Age=1200; Path=/");
printf("%s%s%s\n","Set-Cookie: typ=",type,"; Max-Age=1200; Path=/");
printf("%s\n\n","Set-Cookie: UniqueID=ABCDEF0123456789; Max-Age=1200; Path=/");

...bevor es durch den Compiler gejagt wird.

Ansonsten gelten ja die Vorgaben der Interpretersprache.
Rexx z.B. kennt ja kein printf, da macht es: say "Hello World"

 

[FischersFreetz]

Aber gehe ich recht in der Annahme, daß Du hier: ...
wieder Freetz und Freetz-NG durcheinander geworfen hast?

Nein.

Und noch eine Zwischenfrage meinerseits: Wie kommst Du zu deiner Annahme?

 

[PeterPawn]

Mir war so, als wärst Du einer von denen, die sich lieber mit Freetz-NG befassen wollten.

Wenn das ein Irrtum meinerseits war, bitte ich (a) um Entschuldigung und (b) um Nachsicht - da rauschen schon mal mehrere Leute gleichzeitig vorbei mit Freetz-Problemen und man kann die nicht immer zu 100% auseinanderhalten, wenn die Threads bzw. die Probleme sich dann erledigt haben.

Erst recht dann, wenn da zwei Leute (mit unterschiedlichen Problemen) "simultan" behandelt werden, da bringt man dann (wenn die Threads wie geschrieben mittlerweile auch "abgehakt" sind und es in neuen Threads weitergeht) schon mal Fragesteller durcheinander - solange man die Probleme nicht auch noch verwürfelt, ist das ja kein Beinbruch.

Dann habe ich den Dialog mit Dir (und zwar hier: https://www.ip-phone-forum.de/threa...nand-basierte-fritz-boxen.273304/post-2370272) wohl mit dem mit @Massa (hier: https://www.ip-phone-forum.de/threads/freetzen-einer-7590-mit-fw-7-12.306572/post-2369108 - am Ende dieses Threads überschnitt sich das dann zeitlich mit dem im "modfs"-Thread) durcheinander gebracht.

===================================================================

Vielleicht auch deshalb, weil ich dort auch @Massa explizit gebeten habe, erst dann den nächsten Beitrag im IPPF zu schreiben, wenn er mit den eigenen Versuchen durch ist und der Inhalt eines neuen Beitrags einigermaßen "stabil" ist - es ist ziemlich frustrierend, wenn man auf einen "halbfertigen" Stand eines Beitrags bereits antwortet (der aber trotzdem "Fragen" beinhaltet, die auch erst einmal beantwortet werden wollen, wozu man i.d.R. auch etwas Zeit zum Schreiben braucht), nur um dann festzustellen, daß sich zwischenzeitlich (und dank "Edit" bzw. "Bearbeiten" auch ohne erkennbare Änderung im eigenen Browser-Tab) die Lage bereits wieder geändert hat und zumindest Teile von dem, was man da geschrieben hat in seiner Reaktion, bereits obsolet sind.

Ich finde es ja sogar ausgesprochen begrüßenswert, wenn sich jemand nicht nur auf Antworten anderer verlassen will und wichtige Sachen eher selbst probieren möchte. Aber dann sollte man diese Aktionen auch erst einmal zum Abschluß bringen, bevor man gleich seine Fragen stellt und sich danach dann im Zuge "weiterer Ermittlungen" - parallel zu den Bemühungen anderer - selbst zumindest einen Teil der Antworten gibt und damit anderen den Eindruck vermittelt, sie sollten besser mit ihren Reaktionen erst einmal warten, bis das alles etwas "abgeklungen" ist. Damit macht man sich nur die "prompten Antworten" kaputt und muß dann am Ende damit leben, wenn diese "round trips" entsprechend länger dauern.

 

[koyaanisqatsi]

Ist das so? Oder (nur) deine Meinung?

Hm, ist so.
Allerdings wird dieser Vorteil wieder zunichte gemacht, wenn Shellscript eine 7MB grosse statisch gelinkte PHP Executable aufruft um ein paar "echo"s auszugeben.
...oder "print"s.
...oder "printf"s

 

[FischersFreetz]

... was das für ein merkwürdiges SheBang in der ersten Zeile sein soll? Welche Version einer "bash" unterstützt denn eine (long-)Option "--shell=<something>"? Ich finde im Internet keine Stelle, wo Du das falsch abgeschrieben haben könntest.

Ich habe früher mal "Haserl" ausprobiert und konnte so etwas ähnliches durchaus im Internet finden:

NAME
haserl - A cgi scripting program for embedded environments
SYNOPSIS
#!/usr/bin/haserl [--shell=pathspec] [--upload-dir=dirspec] [--upload-handler=handler] [--upload-limit=limit] [--accept-all] [--accept-none] [--silent] [--debug]
[ text ] [ <% shell script %> ] [ text ] ...
...
--shell=pathspec  Specify an alternative bash-like shell to use. Defaults to "/bin/sh"
To include shell parameters do not use the --shell=/bin/sh format. Instead, use the alternative format without the "=",
as in --shell "/bin/bash --norc". Be sure to quote the option string to protect any special characters.

Aber "natürlich" ist das auf die hier vorliegende Situation nicht übertragbar. (Jetzt ist mir das auch klar.)

Die von dir vorgeschlagende Option "-x" zeigt bei mir zwar in der normalen Shell als auch via
"chroot /var/media/ftp/freetz/lighthttpd/www /bin/bash -x" ihre Wirkung, aber in der Abarbeitung durch den Webserver nicht. Welche Schlussfolgerungen könnte man daraus ziehen?

===================================================================

... bitte ich (a) um Entschuldigung und (b) um Nachsicht ...

Für (a) besteht kaum ein Anlass und (b) sei dir meinerseits garantiert.

 

[PeterPawn]

konnte so etwas ähnliches durchaus im Internet finden:

Da sind das ja auch Optionen für das Programm "haserl" und nicht für die "bash" - da lag/liegt also einer Deiner Irrtümer. Ich kann auch nicht 100% sagen, wie die "bash" reagiert, wenn man ihr beim Aufruf ungültige Optionen vorsetzt ... wenn sie die einfach nur ignoriert und nicht auf POSIX "zurückfällt" (sie kennt einen "bash"- und einen "sh"-Modus, wobei letzterer beim Aufruf als "sh" verwendet wird und mehr oder weniger nur POSIX-Kompatibilität einschaltet), könnte das auch unproblematisch sein.

Letztlich passiert bei so einem "SheBang" ja nichts anderes, als daß das Programm aus dem SheBang so aufgerufen wird, wie es dort steht und gleichzeitig wird STDIN für dieses Programm auf die Datei gesetzt, die dieses SheBang enthält. Daher klappt das i.d.R. auch nur für Sprachen, wo die "Raute" (oder meinetwegen auch das "hash-tag" - #) als Kommentarzeichen fungiert.

Welche Schlussfolgerungen könnte man daraus ziehen?

Zunächst vielleicht mal die Vermutung, daß der Aufruf als CGI beim "lighttpd" anhand der Zuordnung in der Konfiguration erfolgt und nicht anhand des SheBang in der ersten Zeile. In der weiter oben von mir verlinkten Erklärung für Ubuntu, was es mit dem SheBang auf sich hat, sind ja auch ein paar Sätze dazu enthalten, daß das natürlich beim expliziten Aufruf des Interpreteters keine Wirkung entfaltet.

Aber Dir kann trotzdem geholfen werden (ich gehe mal davon aus, daß Du bereits STDERR und STDOUT über exec 2>&1 zusammengelegt hast), denn man kann diese "Debug-Ausgabe" der Shell auch mittels set-Kommando an einer beliebigen Stelle in der Datei nachträglich ein- und auch wieder ausschalten. Das Einschalten erfolgt mittels set -x und das Ausschalten dann mit set +x. Die Alternative wäre die Angabe von Optionen beim "mapping" von Erweiterungen auf den passenden Interpreter ... aber ich weiß nicht, ob "lighttpd" das unterstützt. Das müßte man also ggf. "testen", wenn man nicht mit dem set-Kommando (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#set) arbeiten will.

EDIT: Wenn das Zusammenlegen von STDOUT und STDERR beim "lighttpd" aus irgendeinem Grund nicht funktionieren sollte (obwohl es das müßte), kann man auch mittels server.breakagelog = "<path_to_error_log>" die STDERR-Ausgaben aller CGI-Aufrufe in eine gesonderte Datei ausgeben lassen.

EDIT2: Hier: https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModCGI findet sich dann die Beschreibung der Optionen des "mod_cgi" für "lighttpd" - auch andere Module und "generelle" Optionen sind da dokumentiert.

 

[FischersFreetz]

So... ich glaube, ich hab's (fast) geschaft!? Und an dieser Stelle noch einmal Danke an PeterPawn für deine (seine) Hinweise.

Hier noch mal die wesentlichen Schritte für die Nachwelt:

[x] Erweiterung der lighthttpd.conf um zusätzliche Einträge:

server.modules += ( "mod_cgi" , "mod_setenv" )
cgi.assign = ( ".cgi"  => "/bin/bash" )
setenv.add-environment = ( "SHELL" => "/bin/bash" , "PATH" => "/bin:/usr/bin" )

[x] Bereitstellen der benötigen "Programme" und Bibliotheken in der chroot-Umgebung
Variante 1: Einbinden der Verzeichnisse "/bin" und "/lib" in der chroot-Unmgebung

mount -o bind /bin /var/media/.../lighthttpd/www/bin/
mount -o bind /lib /var/media/.../lighthttpd/www/lib/

oder (dafür habe ich mich entschieden)
Variante 2: Kopieren der "Programme" und Biblitotheken in die chroot-Unmgebung
2.1 Folgende Dateien nach "/var/media/.../lighthttpd/www/bin" kopieren:

• /bin/bash (statisch gelinkt)
• /bin/busyboy
• alle Symlinks auf die busybox in /bin (oder eine gewünschte Auswahl davon)

und zuätzlich noch Symlinks für env und printf auf die busyboy in "/var/media/.../lighthttpd/www/bin" anlegen.
2.2 Folgende Bibliotheken der busybox nach "/var/media/.../lighthttpd/www/lib" kopieren:

• /lib/libm.so.1
• /lib/libc.so.1
• /lib/ld-uClibc.so.0

Mit dem Befehl ldd /bin/busybox erfährt man die benötigen Bibliotheken.

Damit erhalte ich mit folgendem Script:

#!/bin/bash -x
#set -x
#exec 2>&1
datum=$(date)
printf "%s\n" "Content-type: text/plain"
printf "%s\n" "[Hallo Bash] - [$0] - [$datum]"
printf "%s\n" "[env:]" "$(env)"
printf "%s\n" "[\$Bash:]" "$BASH" "$(bash --version)"
printf "%s\n" "[ls:]" "$(ls)"
printf "%s\n" "[\$?] $?"

folgende Ausgabe:

Content-type: text/plain
[Hallo Bash] - [/websites/index.cgi] - [Fri May 22 13:51:28 UTC 2020]
[env:]
SHELL=/bin/bash
LD_PRELOAD=
HTTP_USER_AGENT=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0
HTTP_HOST=192.168.x.x:8008
SERVER_PORT=8008
LD_LIBRARY_PATH=/mod/lib:/mod/usr/lib
DOCUMENT_ROOT=/websites
SCRIPT_FILENAME=/websites/index.cgi
REQUEST_URI=/index.cgi
SCRIPT_NAME=/index.cgi
HTTP_CONNECTION=keep-alive
REMOTE_PORT=62628
PATH=/bin:/usr/bin
PWD=/websites
REDIRECT_STATUS=200
HTTP_ACCEPT_LANGUAGE=de,en-US;q=0.7,en;q=0.3
HTTP_DNT=1
HTTP_ACCEPT=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
REMOTE_ADDR=192.168.x.x
SHLVL=1
SERVER_NAME=192.168.x.x
CONTENT_LENGTH=0
SERVER_SOFTWARE=lighttpd/1.4.45
QUERY_STRING=name=ferretlkdlkdl&kdjsdj=1121123
SERVER_ADDR=192.168.x.x
GATEWAY_INTERFACE=CGI/1.1
HTTP_UPGRADE_INSECURE_REQUESTS=1
SERVER_PROTOCOL=HTTP/1.1
HTTP_CACHE_CONTROL=max-age=0
HTTP_ACCEPT_ENCODING=gzip, deflate
REQUEST_METHOD=GET
_=/usr/bin/env
[$Bash:]
/bin/bash
GNU bash, version 3.2.57(2)-release (mips-unknown-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.
[ls:]
index.cgi
index.html
index.php
[$?] 0

Ich finde, das kann sich erstmal sehen lassen. Ich nehme aber gerne Hinweise und Verbesserungsvorschläge dankend an, besonders zu folgenden Aspekten:

• A1: Wie ließe die vollständige Funktionweise der Bash überprüfen?
• A2: Welche "Stolpersteine" sind noch zu erwarten?
• A3: Was soll dieser Eintrag "LD_LIBRARY_PATH=/mod/lib:/mod/usr/lib" in der env?
• A4: In wiefern beeinträchtigt das Einbinden "externer" Verzeichnisse eine chroot-Umgebung?

 

[koyaanisqatsi]

LD_LIBRARY_PATH kommt eindeutig von Freetz.
...und ist für die nicht statisch gelinkten Binaries von Bedeutung.
Die finden so ihre Funktionbibliotheken ( *.so ).

Das Environment sieht gut aus.
Jetzt kommt es auf deine XML/HTML/CSS/JS Skills an

 

[FischersFreetz]

Ja, aber wie kommt der Eintrag dahin und was soll der da? Die Verzeichnisse erreicht man doch sowieso nicht. Steckt ein tieferer Sinn dahinter?

 

[koyaanisqatsi]

Überleg mal...
Ist Lighthttpd statisch gelinkt?
Wird Lighthttpd erst in der Chrootumgebung gestartet?
Wie genau wird Lighthttpd gestartet ( env -i ? ) ?

 

[FischersFreetz]

... wahrscheinlich nicht ... vermutlich nicht ... keine Ahnung .... Mein Wissen ist begrenzt! ...

 

[FischersFreetz]

Beim Überlegen kam ich auf neue Fragen:

• Was soll dieser Eintrag "LD_PRELOAD=" in der env?
• Wäre das eine Option zum "Übertragen" der geteilten Bibliotheken in die chroot?

Daneben würde mich interessieren, wie ich die neue Version 1.4.55 vom lighthttpd in mein Freetz-Image bekomme könnte? Warten? Selber machen? Und ist Letzteres eine realistische Zielstellung?

 

[koyaanisqatsi]

Such den Eintrag mit dem grünen Häkchen...
https://stackoverflow.com/questions/426230/what-is-the-ld-preload-trick

@FischersFreetz
Du solltest vielleicht noch wissen, dass ein standardmässig aktivierter Mediaserver alle USB-Speicher bereitstellt.
Dafür nutzt er auch einen Webserver, der dann auch deine Chroot-Umgebung lokal verteilen könnte.
...könnte dir eventuell in den Rücken fallen.

[Info] - Dein Freund, der AVM-Mediaserver ... und wie er Dir in den Rücken fallen könnte

Wer von uns kennt nicht den "Mediaserver", der von AVM in Werbevideos und Anleitungen angepriesen wird als Schmalspurlösung für die Bereitstellung von Medien-Dateien auf den an die FRITZ!Box angeschlossenen Speichermedien. Dieser hatte in der Vergangenheit mal das Problem, daß er zu geschwätzig...

www.ip-phone-forum.de

Aber wenn mans weiss, kann er auch prima für eigene Zwecke eingesetzt werden.

 

[FischersFreetz]

Danke für den Hinweis:

[Info] Dein Freund, der AVM-Mediaserver ... und wie er Dir in den Rücken fallen könnte
...

Ist das denn noch aktuell?

Und bei mir ist der Mediaserver deaktiviert. (Ich mag den gar nicht.)

-- Zusammenführung Doppelpost by stoney

Ich komme mit meinen Bash-cgi-Scripten - step by step - immer weiter, aber an einer Problematik scheitere ich:
Ich möchte mit curl einen Download anstoßen. Die Input-Daten kommen via POST.

#!/bin/bash
echo -e "Content-type: text/plain; charset=UTF-8\n"
set -x
exec 2>&1

read -n $CONTENT_LENGTH input
#z.B.:"--header 'Host: ipv4.download.thinkbroadband.com' --user-agent 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0' --header 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' --header 'Accept-Language: de,en-US;q=0.7,en;q=0.3' --header 'DNT: 1' --cookie '__cfduid=d232daa84d0d2c871127f260f90b7fd391590482231' --header 'Upgrade-Insecure-Requests: 1' 'http://ipv4.download.thinkbroadband.com/20MB.zip' --output '20MB.zip'"

curl "$input"   #?????

ergibt folgenden Fehler:

+ read -n 482 input
+ curl '--header '\''Host: ipv4.download.thinkbroadband.com'\'' --user-agent '\''Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0'\'' --header '\''Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8'\'' --header '\''Accept-Language: de,en-US;q=0.7,en;q=0.3'\'' --header '\''DNT: 1'\'' --cookie '\''__cfduid=d232daa84d0d2c871127f260f90b7fd391590482231'\'' --header '\''Upgrade-Insecure-Requests: 1'\'' '\''http://ipv4.download.thinkbroadband.com/20MB.zip'\'' --output '\''20MB.zip'\'''
curl: option --header 'Host: ipv4.download.thinkbroadband.com' --user-agent 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0' --header 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' --header 'Accept-Language: de,en-US;q=0.7,en;q=0.3' --header 'DNT: 1' --cookie '__cfduid=d232daa84d0d2c871127f260f90b7fd391590482231' --header 'Upgrade-Insecure-Requests: 1' 'http://ipv4.download.thinkbroadband.com/20MB.zip' --output '20MB.zip': is unknown
curl: try 'curl --help' for more information

Das "Quotting-Gefummel" bringt mich um den Verstand . Hat jemand einen Tipp für mich?
Das muss doch gehen...

PS: Per eval curl "$daten" habe ich es hinbekommen, aber darauf möchte ich verzichten.

 

[PeterPawn]

Ist doch ganz simpel ... wenn Du um $input Deinerseits "double quotes" setzt, ist alles das, was in dieser Variablen steht, ein einziger Parameter, also eine lange Zeichenkette.

Mal abgesehen davon, daß es sehr, sehr ausführliche Gültigkeitsprüfungen braucht, um so einen Aufruf zu einer guten Idee zu machen.

 

[FischersFreetz]

... wenn Du um $input Deinerseits "double quotes" setzt,...

... Wie meinst du das? Da stehen doch schon welche.

...
curl "$input" #?????

Oder bin ich schon verrückt?

... daß es sehr, sehr ausführliche Gültigkeitsprüfungen braucht...

Kannst du kurz andeuten, woran ich da (noch) denken sollte?