Wenn Du nicht einmal die "Redewendung" "Ruhig Brauner" kennst, dann hilft Dir vielleicht das Internet:
https://www.google.de/search?q=ruhig+brauner
Ansonsten stehe ich zu dem, was ich geschrieben habe ... und bei allen Meinungsverschiedenheiten, die man so haben kann: Wenn Du einfach mit einem :blonk: darüber hinweggegangen wärst, daß Dir das mit den Rechten für die Wurzel nicht selbst sofort aufgefallen ist (Deinen vorhergehenden Fehler mit /dev/random mal außen vor, auch da hast Du Dich nur auf andere verlassen und es selbst ja wohl gar nicht erst geprüft) und dann einfach mit einem "unsquashfs -s filesystem_core.squashfs" gezeigt hättest, daß es bereits bei AVM so ist, dann wäre vielleicht
Hiiri schrieb:
Deiner Hilfsbereitschaft in allen Ehren, aber bleibe bitte bei den Fakten.
Auf deinen Kommentar gehe ich jetzt nicht weiter ein, da es nicht zur Lösung beitragen würde.
bei mir nicht so komisch angekommen - und ja, entschuldige bitte, daß ich mich in Dein Problem vertieft habe und dabei zu Spekulationen gezwungen war und Dir mit einer solchen schlußendlich Unrecht tat - es tut mir ausdrücklich leid, daß ich mit meiner Vermutung daneben lag und ich entschuldige mich dafür.
Welchen "Kommentar" Du nun genau meintest (sofern es nicht der bereits von mir weiter oben zitierte Satz zum "chmod" war), weiß ich allerdings immer noch nicht - meine Bemerkung zu Deinen fehlenden Kenntnissen zu "chmod" und Attributen war ja kein Kommentar, sondern eine Feststellung (sofern Du das nicht übersehen hast - glaube ich eigentlich nicht und selbst wenn, dann kann ich aber auch wieder nichts dafür, welchen Eindruck Du hinterläßt, wenn Du da noch (zweimal) fragst, ob jemandem etwas auffällt).
Wenn Du auf die Ausgabe von
Code:
#httpd -v -p 111 -u www-data:www-data -h /tmp
httpd: [COLOR="#FF0000"]can't open '/': Permission denied[/COLOR]
hin nicht auf die Idee kommst, die Berechtigungen für das Wurzelverzeichnis und Deinen Benutzer einfach mal selbst zu überprüfen und es erst nach 8 Stunden eines weiteren "roundtrips" (und wieder eines längeren Beitrags von mir, wobei ich mich am Ende der Diskussion des Eindrucks ohnehin nicht erwehren kann, daß ich auch an
inhaltlichen Informationen in diesem Thread fast mehr geschrieben habe als Du (CODE-Schnipsel zählen da wohl kaum dazu), was dann wohl daran lag, daß ich ja auch derjenige mit dem zu lösenden Problem war) bedarf, damit Du dort mal nachsiehst (womit wir wieder bei dem Warten und Verlassen auf andere sind), dann finde ich das per se schon ziemlich schwach. Wenn mich jemand ausdrücklich nach Befehlen zum Test fragt, dann erwarte ich auch, daß er testet ... und zwar nicht nur das, was ich ihm mehr oder weniger direkt hingeschrieben habe, sondern auch die anderen Punkte, die ich als Alternativen genannt habe. Ziel war es ja nicht, daß
ich erkennen kann, was bei Dir schief läuft und da ist dann das Aufschreiben irgendwelcher Ergebnisse und das anschließende Warten auf Antwort wohl doch ein Mißverständnis. Hättest Du gefragt: "Mit welchem Befehl teste ich am besten, ob der Benutzer an das Device kommt und wer interpretiert mir hinterher die Ergebnisse?", wäre ich gleich weiterhin "stumm" geblieben.
Aber ich habe tatsächlich auch etwas hierbei gelernt, sowohl inhaltlich (die 7362SL hat andere Rechte im Dateisystem) als auch in Bezug auf künftige Beiträge (spare Dir weitere Reaktionen, wenn Dein erster Hinweis auf fehlende Informationen nicht die erwarteten Früchte trägt ... wenn es nach
einer Aufforderung nicht funktioniert, wird es im Verlauf kaum besser werden).
-Und um auch das noch einmal anzusprechen ... wenn Du tatsächlich nur die Rechte für die Verzeichnisse korrigiert hast (#13, dann auch hoffentlich nicht nur für die Ebenen, die Du im Listing von @Pokemon20021 sehen kannst), dann kannst Du Dir das ganze Hinzufügen der neuen Gruppe eigentlich auch fast sparen.
Solange nämlich die ganzen Dateien in den Unterverzeichnissen auch für "others" alle dieselben Rechte wie für die Gruppe einräumen (die Ausnahmen lassen sich an den Fingern abzählen) , ändert sich durch den Wechsel der Gruppe (beim Benutzer macht das Sinn, weil UID=0 ein Sonderstatus ist) wenig bis gar nichts.
Das Beschreiben von Dateien im SquashFS ist ohnehin nicht möglich, "/wrapper" ist im Normalfall ebenfalls read-only gemountet und in "/var" (dem einzigen beschreibbaren Verzeichnis) sieht es erst einmal auch nicht viel anders aus:
Code:
# tar tvf squashfs-root/var.tar
drwxr-xr-x 0/0 0 2016-10-19 11:59 ./var/
drwxr-xr-x 0/0 0 2016-10-19 11:59 ./var/tmp/
-rwxrwxrwx 0/0 26 2016-10-19 11:58 ./var/tmp/passwd
-rwxrwxrwx 0/0 20 2016-10-19 11:58 ./var/tmp/hosts
-rwxrwxrwx 0/0 50 2016-10-19 11:58 ./var/tmp/resolv.conf
-rw-r--r-- 0/0 0 2016-10-19 11:59 ./var/tmp/nohup.out
-rwxrwxrwx 0/0 10 2016-10-19 11:58 ./var/tmp/group
drwxr-xr-x 0/0 0 2016-10-19 11:58 ./var/tmp/upnpwebsrv/
-rwxrwxrwx 0/0 26 2016-10-19 11:58 ./var/tmp/shadow
drwxr-xr-x 0/0 0 2016-10-19 11:58 ./var/wpa2/
drwxr-xr-x 0/0 0 2016-10-19 11:58 ./var/tam/
drwxr-xr-x 0/0 0 2016-10-19 11:58 ./var/lock/
-rwxrwxrwx 0/0 0 2016-10-19 11:58 ./var/lock/.dummy
drwxr-xr-x 0/0 0 2016-10-19 11:58 ./var/dsl/
drwxr-xr-x 0/0 0 2016-10-19 11:58 ./var/dsl/diagnose/
drwxr-xr-x 0/0 0 2016-10-19 11:58 ./var/dsl/pipe/
lrwxrwxrwx 0/0 0 2016-10-19 11:59 ./var/htmltext.db -> /etc/htmltext_de.db
-rwxrwxrwx 0/0 9222 2016-10-19 11:58 ./var/post_install
drwxr-xr-x 0/0 0 2016-10-19 11:58 ./var/rpc/
-r-xr-xr-x 0/0 0 2016-10-19 11:58 ./var/rpc/.dummy
drwxr-xr-x 0/0 0 2016-10-19 11:58 ./var/log/
-rwxrwxrwx 0/0 0 2016-10-19 11:58 ./var/log/.dummy
drwxr-xr-x 0/0 0 2016-10-19 11:59 ./var/run/
lrwxrwxrwx 0/0 0 2016-10-19 11:59 ./var/run/topology.conf -> /tmp/topology.conf
-rwxrwxrwx 0/0 0 2016-10-19 11:58 ./var/run/.dummy
lrwxrwxrwx 0/0 0 2016-10-19 11:59 ./var/run/cpufreq.kick -> /sys/devices/system/cpu/cpufreq/kick
drwxr-xr-x 0/0 0 2016-10-19 11:58 ./var/dev/
drwxr-xr-x 0/0 0 2016-10-19 11:59 ./var/media/
lrwxrwxrwx 0/0 0 2016-10-19 11:59 ./var/media/devmap -> /var/tmp/mediadevmap
lrwxrwxrwx 0/0 0 2016-10-19 11:59 ./var/web_activity -> run/cpufreq.kick
lrwxrwxrwx 0/0 0 2016-10-19 11:59 ./var/devices -> /var/tmp/usbdevices
(das ist die Laborversion für die 7362SL).
Damit ändert sich durch die Verwendung einer anderen Gruppe (deren Wechsel ist ja das eigentliche Problem) an den Schreibrechten also schon mal gar nichts und das gilt ebenfalls für die "execute"-Rechte, weil die eben (fast) überall für "others" auch dieselben sind wie für die Gruppe.
Somit stellt sich dann die Frage, warum Du überhaupt eine andere Gruppe als "root" verwenden willst und das ist dann auch schon die Wurzel Deines Problems ... es ist ja am Ende die Gruppe, der es final an den Rechten fehlt und nicht der Benutzer, andere Benutzer (s. /etc/passwd) sind halt Member von "GID=0".
Den Sicherheitsgewinn daraus kann ich nicht direkt erkennen (ich lasse mich gerne aufklären - anders als UID=0 ist GID=0 nicht unbedingt ein privilegierter Status, aber ich könnte mich auch irren, falls irgendein Programm (außer welche mit "setgid"-Erfordernis für korrekte Funktion) auch die effektive Gruppe testet) und am Ende - ich weiß ja nicht, wo Du Deinen PHP-Kram und den Hiawatha ablegst - ändert sich das vielleicht für alles, was unter "/var/media/ftp/<usb_device>" gemountet wird, ohnehin wieder mit der nächsten Version, wenn nur noch mit "noexec" gearbeitet wird (oder man muß es rückgängig machen, obwohl es eine sinnvolle Sicherheitseinrichtung ist).
Somit noch einmal der Hinweis (wenn es Dich nicht interessiert, hilft es vielleicht anderen):
Wer einen Service mit einem Nutzer mit eingeschränkten Rechten auf seiner FRITZ!Box betreiben will (generell eine gute Idee), kann das auch gleich richtig machen und den mit "chroot" arbeiten lassen. Nur das (oder das Anpassen der Dateiberechtigungen zur Ausführung - vielleicht sogar zum Lesen - im gesamten SquashFS-Image) führt am Ende dazu, daß ein Fehler im Service, der zum Ausbruch eines Angreifers genutzt werden kann, auf der Box keine weiteren Kommandos finden oder gar starten kann.
Andere Sicherheitserweiterungen (SELinux, Apparmor) unterstützt das FRITZ!OS nicht und damit kann man auch keine feiner granulierten Rechte als die für "others" (wenn der verwendete Benutzer nicht Besitzer oder Gruppe ist) vergeben.
In ein chroot-Jail kopiert man halt nur die Kommandos hinein, die verfügbar sein sollen (Vorsicht, hier ist eine BusyBox mit "PREFER_APPLETS" dann schon wieder ein Stolperstein), legt ein Arbeitsverzeichnis an und mountet lib mit einem "bind"-Mount. Dann noch ein eigenes "dev"-Verzeichnis anlegen, nur die notwendigen Devices erstellen und die Schreibrechte für das neue dev-Verzeichnis einschränken, denn es bringt nichts, wenn da wieder jeder neue Devices anlegen kann. Dann noch die notwendigen Pseudo-Dateisysteme gemountet (das geht bei Pseudos ohne bind) und man hat seine Umgebung beisammen. Ein Beispiel für "chroot" (da allerdings dazu benutzt, um dem aufgerufenen Programm eine "virtuelle Datei" unterjubeln zu können) findet sich in "
decode_passwords". Das dort enthaltene "prepare_chroot" muß man vielleicht etwas für die eigenen Bedürfnisse anpassen (speziell wenn man device-Files erzeugen will), aber dann kann man durch einfache Definitionen von Dateioperationen (in chroot_files) alles notwendige an Dateien für seinen Service zusammenstellen und in der Folge kann selbst ein gekaperter Service nicht weiter als bis zu diesem "verschobenen" Root-Directory kommen. Allerdings setzt das natürlich voraus, daß der dort "eingesperrte" Daemon nicht mit anderen Diensten außerhalb kommunizieren will, sonst müßte man das über Pipes oder (Net-)Sockets lösen.
-Und bevor jetzt jemand anderem auffällt, daß die von mir weiter oben aufgestellte Behauptung, bei AVM würde alles mit der Gruppe "root" laufen, auch nicht (mehr) so ganz den Tatsachen entspricht (das ist auch ein Fakt): Für den RPC-Mechanismus und die NFS-Verbindung zwischen den Systemen auf einer 6490, war dann wohl auch AVM die Gruppe "root" zu heiß (kann auch sein, daß der rpcbind auf "nobody" besteht, habe ich nicht nachgesehen) - da werden "nobody" und "nogroup" sauber angelegt und dann auch verwendet (in S51-nfs).
