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

koyaanisqatsi · 8 Mrz 2013

Das Problem ist folgendes:
Starte ich httpd (aus dem freetz-WebIf)

als -u nobody:nobody (ugid=100.1000) hält es sensible Daten im Environment.
Zum Beispiel das gehashte Passwort vom freetz-WebIf.
(Vermutlich wird das Environment vom freetz-WebIf "stumpf" beim Start des Servers übergeben)

Ich hab mal das Passwort auf "online" gesetzt und poste mal die Ausgabe von ps und die Ausgabe eines CGIs des nobody:nobody Servers:
ps

Code:

 936 nobody     980 S    {busybox} httpd -P /var/mod/root/addwebif.pid -p 0.0.0.0:83 -u nobody:nobody -h /var/mod/root -c /var/mod/root/httpd.conf

-u nobody:nobody CGI gibt env aus:

Code:

CONTENT_TYPE=application/x-www-form-urlencoded
GATEWAY_INTERFACE=CGI/1.1
MOD_EXTERNAL_YEAR_MAX=2099
MOD_MOUNTED_SUB=yes
REMOTE_USER=fritz
WEBIF=mww
ADDWEBIF_REALM=-r HTTP-Dienst
MOD_SHUTDOWN_IGNORE=
[COLOR="#FF0000"]MOD_HTTPD_PASSWD=$1$aqaWmopn$dZt7Sa/9oZIt3g4SpbVnc.[/COLOR]
REMOTE_ADDR=***.***.***.***
LD_LIBRARY_PATH=/mod/lib:/mod/usr/lib
QUERY_STRING=one=1&two=2&true=true&false=false
AUTH_TYPE=Basic
HTTP_USER_AGENT=Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0
REMOTE_PORT=2502
ADDWEBIF_ENABLED=no
ADDWEBIF_LOGF=/var/mod/root/addwebif.log
ADDWEBIF_HOME=-h /var/mod/root
ADDWEBIF_PARAS=-c /var/mod/root/httpd.conf
MOD_RESOLV_DNS=127.0.0.1
MOD_EXTERNAL_OWN_SERVICES=
HTTP_ACCEPT=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
CONTENT_LENGTH=9
ADDWEBIF_PID=-P /var/mod/root/addwebif.pid
MOD_SWAP_SWAPPINESS=60
SCRIPT_FILENAME=/var/mod/root/cgi-bin/env
MOD_IPV6_ASSIGN=
[COLOR="#FF0000"]MOD_HTTPD_USER=root[/COLOR]
HTTP_HOST=***.***.***.***:83
MOD_CROND=yes
MOD_IPV6_FORWARD=no
MOD_SHUTDOWN_LAST=
REQUEST_URI=/cgi-bin/env?one=1&two=2&true=true&false=false
ADDWEBIF_LOG=yes
MOD_STOR_AUTORUNEND=no
MOD_RESOLV_ATTEMPTS=
SERVER_SOFTWARE=busybox httpd/1.21.0
MOD_STOR_PREFIX=uStor
MOD_SHOW_FREETZ_INFO=yes
MOD_CGI_WIDTH=600
MOD_STOR_KILLBLOCKER=no
MOD_HTTPD_PORT=81
MOD_RESOLV_TIMEOUT=
MOD_SHOW_BOX_INFO=yes
ADDWEBIF_IP=0.0.0.0
PATH=/mod/sbin:/mod/bin:/mod/usr/sbin:/mod/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
MOD_SHUTDOWN_FIRST=inetd
MOD_SHOW_MEMORY_USAGE=yes
MOD_MOUNTED_UMOUNT=yes
MOD_MOUNTED_MAIN=yes
MOD_EXTERNAL_WAIT_INFINITE=no
HTTP_ACCEPT_LANGUAGE=de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
HTTP_REFERER=http://***.***.***.***:83/cgi-bin/netstat
SERVER_PROTOCOL=HTTP/1.0
ADDWEBIF_UG=-u nobody:nobody
MOD_EXTERNAL_DIRECTORY=/var/media/ftp/uStor01/external
_cgi_content_width=630
_cgi_width=600
_CGI_STYLES= /style/mod/daemons.css
MOD_SWAP_FILE=
PATH_INFO=
MOD_SKIN=newfreetz
MOD_STOR_USELABEL=no
MOD_HTTPD=yes
REDIRECT_STATUS=200
REQUEST_METHOD=GET
MOD_GET_IP_METHOD=--extquery
MOD_SWAP=no
PWD=/var/mod/root/cgi-bin
_CGI_ID=daemons
MOD_EXTERNAL_FREETZ_SERVICES=yes
SCRIPT_NAME=/cgi-bin/env
ADDWEBIF_PORT=-p 0.0.0.0:83
MOD_EXTERNAL_YEAR_MIN=no

/var/mod/root wurde übrigens vor dem Start auf nobody getauft mit:

Code:

# cd /var/mod/root
chown -R nobody:nobody .

Ohne einen Fix und/oder Verzeichnisschutz halte ich die Auslieferung der Dokumente/CGIs ins www für mehr als bedenklich.
Könnte es dafür eine Lösung geben?

[EDIT]
Start eingeloggt (root) und aus ash mit dem dazugehörigen Startscript (rc.addwebif) nicht aus dem freetz-WebIf sondern direkt aus dem Userverzeichnis (/var/mod/root) ist alles (soweit) in Ordnung:

Code:

# cd /var/mod/root
# ./rc.addwebif start

-u nobody:nobody CGI gibt env aus:

Code:

GATEWAY_INTERFACE=CGI/1.1
CONFIG_WLAN=y
CONFIG_FON_HD=n
CONFIG_USB_STORAGE_USERS=n
CONFIG_USB_HOST_AVM=n
CONFIG_I2C=n
CONFIG_AB_COUNT=2
CONFIG_WLAN_TXPOWER=y
REMOTE_USER=fritz
CONFIG_WLAN_OPENWIFI=n
CONFIG_CAPI_NT=n
CONFIG_JFFS2=n
CONFIG_ONLINEHELP_URL=http://help.avm.de/fritzbox.php?hardware=129&oem=avm&language=de&country=&version=60.04.68&subversion=10172
CONFIG_T38=n
USER=root
CONFIG_STOREUSRCFG=y
CONFIG_NFS=n
ADDWEBIF_REALM=-r HTTP-Dienst
CONFIG_SQLITE=n
CONFIG_CAPI_XILINX=y
CONFIG_UBIK2=n
REMOTE_ADDR=***.***.***.***
LD_LIBRARY_PATH=/mod/lib:/mod/usr/lib
CONFIG_FONGUI2=y
QUERY_STRING=one=1&two=2&true=true&false=false
CONFIG_TAM_ONRAM=n
CONFIG_FONQUALITY=n
CONFIG_USB=n
HOME=/mod/root
GCOV_PREFIX=/var/gcov
OEM=avm
CONFIG_VDSL=n
CONFIG_PRODUKT_NAME=FRITZ!Box Fon WLAN 7113
wlan_cal=**************************
CONFIG_ENVIRONMENT_PATH=/proc/sys/urlader
SSH_TTY=/dev/pts/0
AUTH_TYPE=Basic
HTTP_USER_AGENT=Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0
REMOTE_PORT=2766
CONFIG_USB_HOST_TI=n
ADDWEBIF_ENABLED=no
ADDWEBIF_LOGF=/var/mod/root/addwebif.log
CONFIG_SWAP=n
CONFIG_LED_NO_DSL_LED=y
CONFIG_ASSIST=y
ADDWEBIF_HOME=-h /var/mod/root
ADDWEBIF_PARAS=-c /var/mod/root/httpd.conf
HTTP_ACCEPT=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
CONFIG_SUBVERSION=-freetz-devel-10172
CONFIG_VERSION=04.68
CONFIG_USB_STORAGE=n
CONFIG_CAPI_POTS=y
HWRevision_ATA=1
PS1=\u@\h:\w\$ 
CONFIG_SAMBA=n
CONFIG_WEBSRV=y
ADDWEBIF_PID=-P /var/mod/root/addwebif.pid
SCRIPT_FILENAME=/var/mod/root/cgi-bin/env
CONFIG_RELEASE=1
CONFIG_BLUETOOTH_CTP=n
Language_is_default=yes
HTTP_HOST=***.***.***.***:83
CONFIG_ROMSIZE=8
CONFIG_SERVICEPORTAL_URL=http://www.avm.de/fritzbox-service-portal.php?hardware=129&oem=avm&language=de&country=&version=60.04.68&subversion=10172
CONFIG_FIRMWARE_URL=http://www.avm.de/fritzbox-firmware-update.php?hardware=129&oem=avm&language=de&country=
CONFIG_PRODUKT=Fritz_Box_7113
HWRevision=129
HWRevision_BitFileCount=
ANNEX=B
CONFIG_ACCESSORY_URL=http://www.avm.de/fritzbox_apps.php?hardware=129&oem=avm&language=de&country=&version=60.04.68&subversion=10172
CONFIG_VERSION_MAJOR=60
CONFIG_XILINX=y
CONFIG_BUTTON=y
CONFIG_TR064=n
CONFIG_NQOS=n
CONFIG_ONLINEHELP=y
Country_is_default=yes
LOGNAME=root
REQUEST_URI=/cgi-bin/env?one=1&two=2&true=true&false=false
CONFIG_USB_PRINT_SERV=n
CONFIG_VPN=n
ADDWEBIF_LOG=yes
SERVER_SOFTWARE=busybox httpd/1.21.0
CONFIG_UPNP=n
CONFIG_ETH_COUNT=1
CONFIG_CAPI=y
TERM=xterm
CONFIG_TR069=n
CONFIG_MAILER=n
CONFIG_CDROM_FALLBACK=n
CONFIG_WLAN_WDS=y
CONFIG_DECT=n
ADDWEBIF_IP=0.0.0.0
PATH=/mod/sbin:/mod/bin:/mod/usr/sbin:/mod/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
HTTP_ACCEPT_LANGUAGE=de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
CONFIG_WLAN_1130TNET=n
CONFIG_CAPI_UBIK=n
CONFIG_NAND=n
CONFIG_FAXSUPPORT=n
CONFIG_INSTALL_TYPE=ar7_8MB_xilinx_1eth_2ab_isdn_te_pots_wlan_01427
HTTP_REFERER=http://***.***.***.***:83/cgi-bin/index.cgi
enable_ata=1
CONFIG_WLAN_MADWIFI=n
CONFIG_SRTP=n
CONFIG_IGD=y
SERVER_PROTOCOL=HTTP/1.0
CONFIG_UNIQUE_PASSWD=n
CONFIG_WLAN_WMM=y
CONFIG_DECT_ONOFF=n
CONFIG_FAX2MAIL=n
CONFIG_OEM_DEFAULT=avm
CONFIG_MEDIASRV=n
ADDWEBIF_UG=-u nobody:nobody
CONFIG_ATA=y
CONFIG_HOMEI2C=n
CONFIG_AUDIO=n
CONFIG_BASIS=y
PATH_INFO=
CONFIG_VLYNQ=y
CONFIG_WLAN_1350TNET=y
CONFIG_ECO=n
CONFIG_LOGD=n
CONFIG_VLYNQ_PARAMS=vlynq_reset_bit_0
SHELL=/bin/ash
REDIRECT_STATUS=200
CONFIG_REMOTE_HTTPS=n
CONFIG_WLAN_IPTV=n
CONFIG_USB_WLAN_AUTH=n
CONFIG_HOSTNAME=fritz.fonwlan.box
CONFIG_CDROM=n
CONFIG_MEDIACLI=n
CONFIG_VOL_COUNTER=n
CONFIG_LIB_MATH=y
REQUEST_METHOD=GET
CONFIG_MAILER2=n
CONFIG_AURA=n
ETC_CONFIG_PATH=/etc/init.d/rc.init
CONFIG_WLAN_TCOM_PRIO=n
Language=de
CONFIG_KIDS=n
CONFIG_DECT2=n
CONFIG_SESSIONID=y
CONFIG_CAPI_TE=y
CONFIG_ANNEX=B
CONFIG_WLAN_WPS=n
PWD=/var/mod/root/cgi-bin
Country=049
SSH_CONNECTION=***.***.***.*** 1040 192.168.1.3 22222
CONFIG_VLYNQ0=3
CONFIG_TAM_MODE=0
CONFIG_WLAN_GREEN=n
SCRIPT_NAME=/cgi-bin/env
GCOV_PREFIX_STRIP=5
TZ=CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00
CONFIG_WLAN_SAVEMEM=y
CONFIG_VLYNQ1=0
CONFIG_CAPI_MIPS=n
CONFIG_FONBOOK2=n
OEM_DEFAULT_INDEX=
CONFIG_BLUETOOTH=n
CONFIG_ATA_FULL=n
CONFIG_TAM=n
ADDWEBIF_PORT=-p 0.0.0.0:83
CONFIG_RAMSIZE=16
CONFIG_FON=n
CONFIG_DSL=y
CONFIG_IPTV_4THOME=n

Dann ist alles so wie es sein soll, aber noch nicht so toll.
(Tatsächlich wurde jetzt das env von root übergeben: USER=root LOGNAME=root)
Auch die aus dem env gebildeten Links funktionieren dann wieder:
CONFIG_ACCESSORY_URL
CONFIG_SERVICEPORTAL_URL
CONFIG_ONLINEHELP_URL

Was macht ein Linuxer, um das Environment so zu manipulieren wie er es haben will?
Dieses Thema ist mir echt wichtig
(Und sollte Allen, die auch über das freetz-WebIf Irgendetwas ins www freigeben, wichtig sein)

Zum Download: Entpackkommando: # tar -x -z -f addwebif.tgz # Ins WebIf laden: # ./rc.addwebif load
Die addwebif.cfg und rc.addwebif Variable SCRIPT_DIR='/var/mod/root' gelten als Beispiel,
und sollten entsprechend den Optionen des zu startenden Programmes angepasst werden.
(Die Beispielwebseiten setzen vollkonfigurierbaren httpd voraus: Own errorpages, reverse proxy, -u)
Die Beispielseiten für die MIME-TYPES *.xml *.svg und *.swf (siehe httpd.conf) hab ich rausgelassen damit es nicht so aufträgt.
Nicht vergessen in rc.addwebif SCRIPT_DIR='/var/mod/root' auf eure Örtlichkeit zu ändern!

Struktur des Archives (damit ihr nichts ausversehen überschreibt):

Code:

root@fritz:/var/mod/root# tar -t -z -f addwebif.tgz
[COLOR="#800080"]rc.addwebif
addwebif.cfg
addwebif.cgi
[/COLOR]httpd.conf
index.html
cgi-bin/
cgi-bin/avm_mn
cgi-bin/bd_mn
cgi-bin/cycler
cgi-bin/env
cgi-bin/free
cgi-bin/hd_en
cgi-bin/hd_st
cgi-bin/httpdcfg
cgi-bin/ifconfig
cgi-bin/iframe
cgi-bin/index.cgi
cgi-bin/jscript
cgi-bin/netstat
cgi-bin/ps
cgi-bin/top
cgi-bin/uname
cgi-bin/uptime
css/
css/menu.css
css/style.css
error/
error/e400.html
error/e401.html
error/e402.html
error/e403.html
error/e404.html
error/e500.html
html/
html/index.html
html/stats.xhtml
img/
img/7113.png
img/bg.jpg
img/blank.png
img/button.gif
img/button_black.gif
img/button_blue.gif
img/button_gray.gif
img/button_green.gif
img/button_greyscale.gif
img/button_pink.gif
img/button_red.gif
img/button_rgb.gif
img/button_white.gif
img/button_yellow.gif
img/favicon.ico
javascript/
javascript/koys.js
javascript/ttcf.js

RalfFriedl · 8 Mrz 2013

koyaanisqatsi schrieb:
Starte ich httpd als -u nobody:nobody (ugid=100.1000) hält er trotzdem ungewollt sensible Daten im Environment.

Wie genau hast Du den httpd gestartet?
Das Environment hat es so an sich, dass es an gestartete Prozesse weiter gegeben wird.

Code:
/var/mod/root wurde übrigens vor dem Start auf nobody getauft mit:

Code:

# cd /var/mod/root chown -R nobody:nobody .

Unter dem Gesichtspunkt der Sicherheit halte ich das höflich formuliert für sehr bedenklich.

Ohne einen Fix und/oder Verzeichnisschutz halte ich die Auslieferung der Dokumente/CGIs ins www für mehr als bedenklich.
Könnte es dafür eine Lösung geben?

An Deiner Stelle würde ich mir deswegen keine Gedanken machen. Wenn ein Angreifer ein CGI-Skript auf der Box unterbringen kann, das ihm das Environment anzeigt, kann er das verschlüsselte Passwort sehen. Wenn es ein gutes Passwort ist, braucht er trotzdem sehr lange, bis er damit Zugang zur Web-Oberfläche bekommt.

Durch Deine Änderung oben mit dem chown könnte ein Angreifer, der ein CGI-Skript auf der Box unterbringen kann, gleich vollen root-Zugriff auf die Box erreichen, ohne erst ein Passwort raten zu müssen und den Einschränkungen der Web-Oberfläche unterworfen zu sein.

koyaanisqatsi · 8 Mrz 2013

Die Änderung des Benutzerverzeichnisses von root in nobody:nobody ist wirklich nur zum testen der ganzen Sache.
(Einfacher, weil nobody die Rechte braucht für .pid und .log)

Wenn es so läuft wie es soll wird es in einem extra dafür vorgesehenen (User?)Verzeichnis ablaufen.
Am liebsten würd ich natürlich nur ein Environment übergeben wollen mit den dafür notwendigen Daten und nicht mehr.
Vielleicht auch nobody besser konfigurieren und httpd von root über su/sudo nobody starten.

RalfFriedl · 8 Mrz 2013

Es hat schon seinen Grund, dass ich gefragt habe, wie Du den den httpd gestartet hast.
Es sieht aus, als würdest Du das Programm aus [THREAD=257269][HowTo] Eigene Inhalte auf Port 80 per Freetz Webif[/THREAD] von einem gewissen realmeto oder meto, modifiziert von koyaanisqatsi, verwenden. Wenn Du damit Probleme hast, wende Dich an die Autoren.

koyaanisqatsi · 8 Mrz 2013

Lösungsansatz

Nun, denn, nach deinem "Autoren" Hinweis, bin ich kurz in mich selber gegangen und habe beschlossen:
"Dann mach ichs mir einfach Einfach"
Nehm das Environment vom freetz-WebIf und nimm die Variable MOD_HTTPD_PASSWD raus.
Und realmeto hat sich bis jetzt nicht gemeldet, dankeschön für den Hinweis.
(Seine Version lief übrigens nicht mal Ansatzweise auf meiner gefreetzten 7113)
Genau dass hab ich ihm hier geschildert.
Hättest du gelesen worauf du hinweisen und verlinken tust, wäre dir dass vielleicht nicht entgangen.

Ich hab also MOD_HTTPD_PASSWD einfach mal auf export MOD_HTTPD_PASSWD='' gesetzt.
Dasselbe mit MOD_HTTPD_USER und gut ists.

Demnach:

Code:

CONTENT_TYPE=application/x-www-form-urlencoded
GATEWAY_INTERFACE=CGI/1.1
MOD_EXTERNAL_YEAR_MAX=2099
MOD_MOUNTED_SUB=yes
REMOTE_USER=fritz
WEBIF=mww
ADDWEBIF_REALM=-r HTTP-Dienst
MOD_SHUTDOWN_IGNORE=
[COLOR="#FF0000"]MOD_HTTPD_PASSWD=[/COLOR]
REMOTE_ADDR=192.168.1.18
LD_LIBRARY_PATH=/mod/lib:/mod/usr/lib
QUERY_STRING=one=1&two=2&true=true&false=false
AUTH_TYPE=Basic
HTTP_USER_AGENT=Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
REMOTE_PORT=53836
ADDWEBIF_ENABLED=no
ADDWEBIF_LOGF=/var/mod/root/addwebif.log
ADDWEBIF_HOME=-h /var/mod/root
ADDWEBIF_PARAS=-c /var/mod/root/httpd.conf
MOD_RESOLV_DNS=127.0.0.1
MOD_EXTERNAL_OWN_SERVICES=
HTTP_ACCEPT=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
CONTENT_LENGTH=9
ADDWEBIF_PID=-P /var/mod/root/addwebif.pid
MOD_SWAP_SWAPPINESS=60
SCRIPT_FILENAME=/var/mod/root/cgi-bin/env
MOD_IPV6_ASSIGN=
[COLOR="#FF0000"]MOD_HTTPD_USER=[/COLOR]
HTTP_HOST=192.168.1.3:83
MOD_CROND=yes
MOD_IPV6_FORWARD=no
MOD_SHUTDOWN_LAST=
REQUEST_URI=/cgi-bin/env?one=1&two=2&true=true&false=false
ADDWEBIF_LOG=yes
MOD_STOR_AUTORUNEND=no
MOD_RESOLV_ATTEMPTS=
SERVER_SOFTWARE=busybox httpd/1.21.0
MOD_STOR_PREFIX=uStor
MOD_SHOW_FREETZ_INFO=yes
MOD_CGI_WIDTH=600
MOD_STOR_KILLBLOCKER=no
MOD_HTTPD_PORT=81
HTTP_COOKIE=page=enhsettings; menu=enhsettings
MOD_RESOLV_TIMEOUT=
MOD_SHOW_BOX_INFO=yes
ADDWEBIF_IP=0.0.0.0
PATH=/mod/sbin:/mod/bin:/mod/usr/sbin:/mod/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
MOD_SHUTDOWN_FIRST=inetd
MOD_SHOW_MEMORY_USAGE=yes
MOD_MOUNTED_UMOUNT=yes
MOD_MOUNTED_MAIN=yes
MOD_EXTERNAL_WAIT_INFINITE=no
HTTP_ACCEPT_LANGUAGE=de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
HTTP_REFERER=http://192.168.1.3:83/cgi-bin/index.cgi
SERVER_PROTOCOL=HTTP/1.0
ADDWEBIF_UG=-u nobody:nobody
MOD_EXTERNAL_DIRECTORY=/var/media/ftp/uStor01/external
_cgi_content_width=630
_cgi_width=600
_CGI_STYLES= /style/mod/daemons.css
MOD_SWAP_FILE=
PATH_INFO=
MOD_SKIN=newfreetz
MOD_STOR_USELABEL=no
MOD_HTTPD=yes
REDIRECT_STATUS=200
REQUEST_METHOD=GET
MOD_GET_IP_METHOD=--all
MOD_SWAP=no
PWD=/var/mod/root/cgi-bin
_CGI_ID=daemons
MOD_EXTERNAL_FREETZ_SERVICES=yes
SCRIPT_NAME=/cgi-bin/env
ADDWEBIF_PORT=-p 0.0.0.0:83
MOD_EXTERNAL_YEAR_MIN=no

Soll mir so reichen.

Status auf [GELÖST] gesetzt, bitte schliessen.

RalfFriedl · 9 Mrz 2013

koyaanisqatsi schrieb:
Hättest du gelesen worauf du hinweisen und verlinken tust, wäre dir dass vielleicht nicht entgangen.

Mir ist durchaus aufgefallen, dass das ursprünglich von realmeto stammt und dann von Dir geändert wurde. In dem Thread habe ich aber nur die ursprüngliche Version gefunden und nicht die von Dir veränderte. Das hättest Du auch direkt schreiben können, dann hätte ich nicht danach suchen müssen.

Du kommst also hierher mit einem Problem, das zum einen kein wirkliches Problem ist, verwendest ein Programm, das nicht zu Freetz gehört und das Du auch noch selbst verändert hast, von dem die veränderte Version entweder überhaupt nicht verfügbar ist oder zumindest nicht so leicht zu finden, und erwartest dann auch noch Unterstützung dabei, Dein Problem zu lösen?

koyaanisqatsi · 9 Mrz 2013

Eh, ja.
Warum soll ich denn etwas zur Verfügung stellen, von dem ich nicht überzeugt bin, dass es anderen Anwendern nicht schadet?
(Schwarzhut Allüren? - Nee, danke!!!)
Zitat:In dem Thread habe ich aber nur die ursprüngliche Version gefunden und nicht die von Dir veränderte. Das hättest Du auch direkt schreiben können, dann hätte ich nicht danach suchen müssen.
Warum fragst du mich nicht? Ist doch erste Adresse hier, oder nicht?
Das changewebif von realmeto, sowie WOL, vnstat, und überhaupt alles was von freetz ins www gestellt werden kann haben dasselbe Environment.
(Ein Sicherheitsaspekt also, wie gaaaanz oben am Ende extra hervorgehoben wurde, scheint nicht von Interesse zu sein)
changewebif ist, solange nix anderes behauptet wird, Freie Software, Open Source.
Jeder kann es also für sich benutzen/abändern oder was auch immer.
Was ich somit auch getan habe, weil zumindest ich einen Bedarf für solch ein "Programm" habe.
Andere Leute, auch hier im Forum streben andere Lösungen* an.
Für sowas* reichen meine Kisten nicht aus.
(Für mich ist es nichts anderes als ein Plugin für freetz, welches sich während der Laufzeit ein/ausbinden läßt)
Somit ist es, meineserachtens, auch nicht nötig, es auf Teufel komm raus in die freetz packages aufzunehmen.
Wenn Interesse bestehen würde, sieht die Sache natürlich anders aus.
Aber, wie ich an deiner Reaktion sehe, war es ein Riesenfehler von mir.
Ich werde darum jegliche öffentliche Entwicklung an addwebif** einstellen.
(Mittlerweile komm ich mit der Rudishell so gut klar, dass ich es nicht mal mehr benötige, Rudi macht sogar dropbear und sftp-server weitgehendst überflüssig)
Die Idee kann dann ja Jemand anderes aufgreifen.
Wie wärs mit dir?

* (Apache mit fett PHP und allem drum und dran)
** (Rest in peace)

[GELÖST] kann also geschlossen werden, danke

RalfFriedl · 9 Mrz 2013

koyaanisqatsi schrieb:
Warum soll ich denn etwas zur Verfügung stellen, von dem ich nicht überzeugt bin, dass es anderen Anwendern schadet?

Du stellst also nur etwas zur Verfügung, wenn Du überzeugt bist, dass es anderen Anwendern schadet?

Warum fragst du mich nicht? Ist doch erste Adresse hier, oder nicht?

Die allererste Frage, die ich gestellt hatte, war, wie genau Du den httpd gestartet hast. Da hättest Du ja auch drauf schreiben können mit dem Skript xy, oder besser noch den Quelltext hier einfügen, da das Skript ja wohl nicht übermäßig lang ist.

Das changewebif von realmeto, sowie WOL, vnstat, und überhaupt alles was von freetz ins www gestellt werden kann haben dasselbe Environment.

Vielleicht, vielleicht auch nicht.
Der httpd, der von Freetz für die Konfiguration gestartet wird (/usr/bin/webcfg), hat als Environment nur PATH und WEBIF, sonst nichts.

Ein Sicherheitsaspekt also, wie gaaaanz oben am Ende extra hervorgehoben wurde, scheint nicht von Interesse zu sein

Du hast noch immer nicht geschrieben, was genau das Problem ist.

changewebif ist, solange nix anderes behauptet wird, Freie Software, Open Source. Jeder kann es also für sich benutzen/abändern oder was auch immer.

Ich habe weder vor, es zu benutzen, noch es zu verändern. Du hast ein Problem damit, und das Mindeste ist, dass Du es potentiellen Helfern nicht unnötig schwer machst.

Ich werde darum jegliche öffentliche Entwicklung an addwebif**einstellen.

Wie traurig

Die Idee kann dann ja Jemand anderes aufgreifen. Wie wärs mit dir?

Warum sollte ich? Du schreibst ja selbst, dass nicht einmal mehr Du es benötigst.

koyaanisqatsi · 9 Mrz 2013

Interessante Argumentation, ich werd mal ne runde drüber meditieren.

Natürlich mein ich genau das Gegenteil, sorry: "Warum soll ich denn etwas zur Verfügung stellen, von dem ich nicht überzeugt bin, dass es anderen Anwendern schadet?"

[GELÖST] Ich habe fertig, Flasche leer.

olistudent · 10 Mrz 2013

Wäre es möglich, dass wir hier wieder zum Thema zurück kehren? Ich vermute, dass das Webinterface über den AVM ctlmgr bereitgestellt wird? Da in rc.changewebif ja nur der Inhalt von /var/html ausgetauscht wird. Dann sollten wir mal schauen wie der ctlmgr gestartet wird.

Gruß
Oliver

koyaanisqatsi · 10 Mrz 2013

Danke, noch mal bei Null anfangen wäre schön...

Zum Start.
Das wesentliche:
rc.addwebif

Code:

SERVICE=httpd
DAEMON_FULL=WebServer

start_ch () {
        if [ -f /var/lock/$SERVICE ]; then
                echo $SERVICE" ist an"
        else
                #  SERVICE starten
                statuslog $DAEMON_FULL":" $SERVICE" wird gestartet" "1"
                $SERVICE -h $ADDWEBIF_HOME $ADDWEBIF_PARAS
        fi
}

(von den Funktionen load/unload in rc.addwebif(von rc.changewebif) hab ich die Finger gelassen, also identisch)
Die Variablen $ADDWEBIF_HOME und $ADDWEBIF_PARAS stehen in addwebif.cfg:
addwebif.cfg

Code:

export ADDWEBIF_ENABLED='no'
export ADDWEBIF_LOG='no'
export ADDWEBIF_LOGF='/mod/root/addwebif.log'
export ADDWEBIF_HOME='/mod/root'
export ADDWEBIF_PARAS='-u nobody.nobody -c /mod/root/httpd.conf'

...logisch wie das da drin steht ists dann natürlich (und muss) im Environment sein.
Dazu sollten dann noch die* vom httpd (für die CGIs), geht auch.
Aber eben am allerliebsten die* vom freetz-WebIf nicht (und die von root natürlich auch nicht).

*Environmentvariablen

olistudent · 10 Mrz 2013

Wo kommt das denn jetzt her? Ich hatte aus dem changewebif.zip folgenden Codeschnipsel:

Code:

start_ch () {
	if [ $(ls /var/html | grep -c "index.lua") -eq 1 ]; then 
		#  Seiten "loeschen"
		statuslog "EIGENE:" "Es wird auf eigene Inhalte umgestellt." "1"	
		rm /var/html
		ln -s $CHANGEWEBIF_HOME /var/html
	else
		echo "Es ist nichts zu tun. Alternativer Webinhalt läuft bereits."
	fi
}

edit: Achso. Der Link geht zum original Plugin. Ging für mich nicht so klar hervor.

koyaanisqatsi · 10 Mrz 2013

Ja, das mit dem Link aufs Original, wollte mich halt nicht mit fremden Federn schmücken.
Das ging irgendwie nach Hinten los. RalfFriedl versteh ich mittlerweile.
Ich dachte auch nicht dass der jetzige Code für das Problem was ich damit hab so wichtig ist.
Aber es löst anscheinend echte Verständigungsprobleme aus, ich entschuldige mich dafür.

hermann72pb · 10 Mrz 2013

@koyaanisqatsi: Wenn du hier so emotional weiter unterwegs sein willst, dann lass die Entwicklung an deinem selbst erfundenen Paket lieber sein. Bevor du hier Ralf und weitere Gurus anschreist und nervst, solltest du dich zunächst hier im Forum umschauen und die hier üblichen Umgangsformen aneignen. Ich bin hier für meine relativ seltenen aber ziemlich direkten Aussagen bekannt. Und ich sage dir: Ralf hat Recht. Hör bitte auf damit, hier alle mit zunächst DEINEN und nicht unseren Problemen zu belästigen. Wenn du willst, das man DIR bei Lösung DEINER Probleme hilft, dann versetze dich zunächst in die Lage denjenigen, der dir helfen soll. Und dann beantworte dir ganz neutral gesehen eine einzige Frage: WARUM muss er das für DICH tun? Wenn du zumindest darüber nachdenkst, dann wird dir hoffentlich klar, WIE du deine Beiträge hier zu gestalten hast und WIE sich hier zu benehmen.

Aber zurück zum Thema. Du brauchst darauf nicht gesondert zu reagieren. Oliver hat auch Recht: Man sollte on topic bleiben!

MfG

olistudent · 10 Mrz 2013

Es ist scheinbar schwer on-Topic zu bleiben? :mrgreen:

koyaanisqatsi · 10 Mrz 2013

Mich düngt auch dass das Thema sowieso an freetz vollkommen vorbeigeht und doch eher ein Betriebssystem Ding ist.
Schon logisch wenn sich da einige Leute von euch drüber pikieren, besonders RalfFriedl (sorry).
Also werd ich mich doch näher mit den Basics darüber beschäftigen müssen.

olistudent · 11 Mrz 2013

Ich bleibe hartnäckig und möchte nochmal auf das Thema zurück kommen...

Gibt es dein Paket in der aktuellen Version jetzt irgendwo zum Download? Ich würde das gerne näher untersuchen.

Gruß
Oliver

RalfFriedl · 11 Mrz 2013

Ok, on Topic.
1. Gibt es eine Begründung, warum das beobachtete Verhalten ein Problem ist? Ich habe hier bisher nur die Behauptung in den Raum gestellt gesehen, aber keine Begründung, was genau das Problem damit ist.
2. Wie schon oben erwähnt, hat der von Freetz gestartete httpd genau zwei Variablen im Environment, PATH und WEBIF, und die sind mit Absicht drin. Es gibt also eine einfache Lösung, und Freetz verwendet sie bereits. Das war auch der Hauptgrund, warum ich gefragt hatte, wie der httpd gestartet wird. Wenn er nämlich über den vorhandenen Mechanismus in Freetz gestartet wird, hat er nur die benötigten Werte im Environment, also muss es einen Grund dafür geben, wenn es hier anders ist.

koyaanisqatsi · 11 Mrz 2013

Ich hab ein .tgz geschnürrt und im ersten Post eingestellt.
Ich konnte es aber nur auf einer Fritz!Box 7113 testen.
Von der Logik her sollte es mit jeder Box funktionieren.
Aber, wer weiß dass schon.

zu 1.) Die Begründung des Problems ist simple:
Das (addwebif) Environment soll kein (gehashtes) freetz-WebIf Passwort enthalten.
Weil ich das nicht für sicher halte für ins www gestellte HTMLs und CGIs.
Das mag jetzt mein subjektives Empfinden sein (hermann72pb: ...so emotional...), ich hab tatsächlich kein gutes Gefühl dabei.

zu 2.) Hm, ich bin mir nicht sicher ob ich das vollständig verstehe.
Möglicherweise hat es etwas damit zu tun, wie das CGI ins WebIf (über die load Funktion in rc.add/change/webif) eingebunden wird. Die ich nicht editiert habe.
Und ich bin ja auch dankbar dafür, das über das freetz-WebIf* nicht auch noch das Environment von root übergeben wird.
*(Vergleiche erste(freetz-WebIf) und zweite(Konsole) Ausgabe des env im ersten Post)

PS: @Oliver: hartnäckig, find ich gut, sonst wär freetz nie soweit gekommen

RalfFriedl · 11 Mrz 2013

koyaanisqatsi schrieb:
Weil ich das nicht für sicher halte für ins www gestellte HTMLs und CGIs.

Das habe ich schon mitbekommen. Hast Du aber ein konkretes Szenario, wo es einen Unterschied macht?

Ansonsten übernimm doch einfach die Lösung von Freetz:

Code:

SERVICE=httpd
DAEMON_FULL=WebServer

start_ch () {
        if [ -f /var/lock/$SERVICE ]; then
                echo $SERVICE" ist an"
        else
                #  SERVICE starten
                statuslog $DAEMON_FULL":" $SERVICE" wird gestartet" "1"
                [B]env -i "PATH=$PATH" [/B]$SERVICE -h $ADDWEBIF_HOME $ADDWEBIF_PARAS
        fi
}

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

IPPF-Urgestein

Anhänge

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Promi

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

Statistik des Forums