Wer sich den LCR auf diesem Weg installiert, sollte sich aber auch über ein paar "Besonderheiten" der Installation im Klaren sein.
Mit "nicht mehr zeitgemäß" ist der Installationsvorgang nämlich (zumindest in meinen Augen) noch nett umschrieben.
Weshalb sehe ich das so?
Aus dem Aufruf
Code:
wget -O - http://telefonsparbuch.de/software/fritzbox/lcr_620 | sh
wird die Ausführung des folgenden Shell-Skripts:
Code:
#!/bin/sh
# wget -O - http://telefonsparbuch.de/software/fritzbox/lcr_620 | sh
wget -qO /var/tmp/tsb.tar http://lcr.telefonsparbuch.de/software/fritzbox/TelefonSparbuch_TSBinstaller_test_1.50.45.tar
tar -C /var/tmp -xf /var/tmp/tsb.tar
sh /var/tmp/var/install usb
if [ -x /var/media/ftp/FritzLoad/bin/install.sh ];then
/var/media/ftp/FritzLoad/bin/install.sh /var/media/ftp/FritzLoad/bin -g
fi
Es wird also die Datei von
http://lcr.telefonsparbuch.de/software/fritzbox/TelefonSparbuch_TSBinstaller_test_1.50.45.tar geladen, "zu Fuß" entpackt (das machte früher der Installationsprozess der AVM-Firmware, solange noch unsignierte Dateien ladbar waren über das GUI) und dann das dort enthaltene Skript "/var/install" mit dem Parameter "usb" aufgerufen.
Lädt man sich das Archiv und schaut in dieses Shell-Skript (hier mit einem Beautifier etwas aufgehübscht, im Original beginnt jede Zeile in Spalte 1), sieht das so aus:
Code:
#!/bin/sh
driveWritable(){
local file=$1
chmod 0777 "${file%/*}" ${file%/*}/* 2>/dev/null
touch $file 2>/dev/null || return 1
if [ -f $file ];then
rm -f $file 2>/dev/null || return 1
return 0
fi
return 1
}
installonexit=0
TSBitype=debug
installType=$1
[ -z "$installType" -a -e /var/tmp/lcritype ] && installType=$(cat /var/tmp/lcritype)
if [ -n "$installType" ];then
check_installed=$2
if [ "$check_installed" = check -a -e /var/tmp/lcrdone ];then
echo "LCR Updater bereits installiert";
exit 0;
fi
TSBupdate=
if [ "$installType" = 'calllog' ];then
TSBitype=calllog
f=/var/flash/calllog
installonexit=1
elif [ "$installType" = 'fehm' ];then
TSBitype=fehm
f=/var/InternerSpeicher/lcrtsb/install
mkdir -p 0777 /var/InternerSpeicher/lcrtsb
installonexit=1
elif [ "$installType" = 'debug' ];then
f=/var/flash/debug.cfg
installonexit=1
elif [ "$installType" = 'usb' ];then
TSBitype=usb
f=
ftp=/var/media/ftp
data=TSB/lcr.data
if [ -d $ftp ];then
if driveWritable $ftp/lcrtest;then
f=$ftp
else
for DRIVE in $(ls -l $ftp | sed -n 's/.* \([^ ].*\)/\1/p');do
if driveWritable $ftp/$DRIVE/lcrtest;then
if [ -f "$ftp/$DRIVE/$data" ];then
f=$ftp/$DRIVE
break
fi
[ -z "$f" ] && f=$ftp/$DRIVE
fi
done
fi
fi
if [ -n "$f" ] && mkdir -pm 0777 $f/TSB 2>/dev/null;then
f=$f/$data
if [ ! -e $f -a -e /var/flash/debug.cfg ];then
echo "Keine LCR Daten vorhanden, versuche Daten aus debug.cfg zu übernehmen"
tmpf=/var/flash/debug.cfg
sed -n "/^\(#LCR\|export TSB\)/p" $tmpf >$f
fi
else
echo "WARNUNG - Kann kein Datenverzeichnis anlegen: $f"
f=/var/flash/debug.cfg
fi
echo "Datenverzeichnis: $f"
installonexit=1
else
echo "Installationsort $installType unbekannt"
exit 0
fi
else
f=/var/flash/debug.cfg
fi
[...]
(es geht noch weiter, aber der Teil, warum ich von der Verwendung abrate (zumindest bei einigen), ist bereits erkennbar).
Was passiert hier denn, wenn man das Skript mit "usb" als Parameter aufruft?
Neben ein paar anderen Aktionen wird die Variable "ftp" auf den Wert "/var/media/ftp" gesetzt, das ist bekanntlich die Basis des NAS-Speichers in der FRITZ!Box und - spätestens seit der 7390 - auch das Verzeichnis, in dem das YAFFS2-Dateisystem gemountet wird. Anschließend wird noch getestet, ob es sich bei "/var/media/ftp" um ein Verzeichnis handelt ("if [ -d $ftp ] ...").
Um festzustellen, ob dieses Verzeichnis beschreibbar ist und damit für die Speicherung des LCR verwendet werden kann, wird die Funktion "driveWritable()" aufgerufen, mit der Angabe "$ftp/lcrtest" als Parameter, was ja dann in "/var/media/ftp/lcrtest" aufgelöst wird.
Die ersten zwei Zeilen in dieser Funktion sehen aber so aus:
Code:
local file=$1
chmod 0777 "${file%/*}" ${file%/*}/* 2>/dev/null
Es wird also der übergebene Parameter (in unserem Fall "/var/media/ftp/lcrtest") der Variablen "file" zugewiesen und danach ein "chmod"-Kommando aufgerufen, was für die angegebenen Namen die Rechte "r","w" und "x" für wirklich jeden (Besitzer, Gruppe, andere) setzt.
Bei den Dateinamen für dieses Kommando handelt es sich aber nicht etwa um den übergebenen Parameter ... mit der Angabe "${file%/*}" wird alles nach dem letzten Schrägstrich im Namen abgeschnitten. Das ergibt dann "/var/media/ftp" für den ersten Namen im "chmod"-Aufruf und "/var/media/ftp/*" für den zweiten.
Damit werden also für alle existierenden Inodes in "/var/media/ftp" (allerdings nicht rekursiv) die Dateirechte geändert, vollkommen ungeachtet dessen, was da bisher eingestellt war.
Das führt jedwede andere Einstellung, die der Besitzer der Box da zuvor vorgenommen haben kann/könnte, ad absurdum ... ich kann auch den Sinn nicht richtig nachvollziehen. Zumindest nicht bei den Modellen, wo "/var/media/ftp" nicht einfach nur ein (volatiles) Verzeichnis im "tmpfs" ist und soo neu ist eine 7390 ja jetzt auch nicht mehr ... entweder der Benutzer hat dort Schreibrechte (und auch das Recht, Verzeichnisse zu traversieren) oder er hat sie nicht. Warum es da irgendetwas helfen soll, wenn man (mutmaßlich ja als "root") jetzt der ganzen Welt alle Rechte auf allen Dateien (und Unterverzeichnissen) in diesem Verzeichnis einräumt, verstehe ich nicht.
Aber am Ende hat man auch noch Glück, wenn das Verzeichnis tatsächlich beschreibbar ist ... denn das, was danach käme, ist noch schlimmer.
Dort würde dann mit folgender Schleife:
Code:
for DRIVE in $(ls -l $ftp | sed -n 's/.* \([^ ].*\)/\1/p');do
if driveWritable $ftp/$DRIVE/lcrtest;then
if [ -f "$ftp/$DRIVE/$data" ];then
f=$ftp/$DRIVE
break
fi
[ -z "$f" ] && f=$ftp/$DRIVE
fi
done
der Test "driveWritable()" für jede Datei(!) und jedes Unterverzeichnis in "/var/media/ftp" noch einmal wiederholt und dabei sollte man besser nicht darüber nachdenken, was denn passieren würde, wenn das Skript auf einen symbolischen Link in "/var/media/ftp" trifft ... der hat nämlich dann an letzter Stelle in der Zeile das Ziel des Links stehen und das landet dann in der Variablen "DRIVE".
Mit passender Konstruktion (ein paar ".." für übergeordnete Verzeichnisse) ist man da ruck-zuck auch in "/var" direkt gelandet (und damit an einer Stelle, wo nur noch volatile Speicherung möglich ist).
Alles in allem sieht das Skript eher so aus, als wäre es seit mind. 5 Jahren praktisch unverändert und das ist noch extrem kurz geschätzt. Alles das, was (auch seitens AVM beim NAS) danach kam, wird praktisch nicht berücksichtigt ... vom Fehlen jeglicher Absicherung vor dem "sh" in der "debug.cfg" ganz zu schweigen.
Zwar stelle ich selbst auch TAR-Files bereit und gebe "Anleitungen", wie man darin enthaltene Skript-Dateien starten kann ... aber das läuft eben nicht automatisch, wie das ja hier wohl "empfohlen" wird, wenn dieser Einbau in die "debug.cfg" tatsächlich vom Autoren so vorgesehen ist. Wenn man tatsächlich
automatisch Skript-Dateien aus dem Internet nachlädt (auch noch über ungesicherte Verbindungen), dann sollte man zumindest irgendeine Prüfung der geladenen Dateien vornehmen, bevor man darin enthaltene Shell-Skripte starten läßt (das gilt also schon für die "lcr_620").
Die dazu notwendigen Werkzeuge wären ja vorhanden ... die Zeiten, wo man irgendetwas unbesehen installieren konnte, sind nun mal auch lange vorbei. Wenn es jemandem gelingt, die Domain "telefonsparbuch.de" zu spoofen, dann wird aus dem billigeren Telefonieren dank LCR ggf. ganz schnell das genaue Gegenteil.
