[Gelöst] Freetz-NG: Fehler in der Verwaltung von Freetz Benutzern (7520/7530 7.2x ggf. weitere Modelle betroffen)

[Fox.Mulder]

Hallo,
bei der 7520/7530 habe ich einen Fehler in der Benutzerverwaltung festgestellt.

Das Problem tritt ab der 7.2x Firmware bei Fritzbox 7520/7530 (ARM Prozessor) auf. Cuma/fda hat den Preload von libctlmgr ab 7.2x für viele/alle? Geräte entfernt, da unterschiedliche libc Versionen für AVM (1.0.31) und Freetz (1.0.37) verwendet werden. Der Fehler hat mit modusers primär nichts zu tun und kann darin nicht gelöst werden. In libctlmgr sieht man, wofür dieses Modul verantwortlich ist. Die vom ctlmgr aufgerufene libc-Funktion rename() wird durch den Aufruf eines speziellen Codes aus libctlmgr ersetzt, worin das Umbenennen der Datei /etc/passwd.tmp in /etc/passwd abgefangen und stattdessen modusers update aufgerufen wird. Das wird deshalb gemacht, da der ctlmgr in bestimmten Situationen /etc/passwd mit den ihm bekannten AVM Benutzern überschreibt. Freetz Benutzer sind dem ctlmgr nicht bekannt. Über den Aufruf von modusers update anstelle Ausführung von rename der vom ctlmgr erzeugten passwd.tmp Datei werden die Freetz Benutzer wieder eingetragen, bevor passwd überschrieben wird. Deshalb ist dieser Hook zwingend erforderlich. Als Lösung sehe ich nur die Verwendung der gleichen libc Version in Freetz wie in der AVM FW, um preload von libctlmgr zu reaktivieren.

@olistudent , siehst Du eine andere Möglichkeit, das Problem zu lösen, wenn weiterhin unterschiedliche libc Versionen für AVM und Freetz verwendet werden?

Anmerkung: Es kann natürlich sein, dass die Aktualisierung der Benutzer in /etc/passwd durch den ctlmgr bei der 7590 funktioniert, weil es aufgrund von musl vs. libc anders implementiert wurde. Ggf. sind weitere Boxen von diesem Fehler in freetz-ng betroffen.

Testablauf:
ssh fritz.box
adduser test -G users -h /var/media/ftp
passwd test
modusers save
modsave flash
# Nachsehen, ob Benutzer test in /etc/passwd, /etc/group und /etc/shadow vorhanden ist.
reboot
# Neustart abwarten und in /etc/passwd nachsehen, ob der Benutzer test vorhanden ist oder nicht. Benutzer test befindet sich weiterhin in /etc/group und /etc/shadow. Deshalb kann dieser Benutzer nicht neu angelegt werden. Korrektur muss mit einem Editor manuell erfolgen. Danach müsst Ihr wieder modusers save; modsave flash ausführen, damit die Änderungen persistent gespeichert werden.

PS: Ich habe cuma/fda über den Fehler informiert. Ihr könnt das im inzwischen geschlossenen Issue im freetz-ng GIT nachlesen.

 

[NDiIPP]

Ihr könnt das im inzwischen geschlossenen Issue im freetz-ng GIT nachlesen.

Sowas gerne gleich verlinken, ich mache es mal hiermit:
https://github.com/Freetz-NG/freetz-ng/issues/236

 

[PeterPawn]

Schon das Vorgehen, sich per Preloading in das Umbenennen einzuklinken, ist wohl "ererbt" und wurde nie überarbeitet bzw. mal hinterfragt.

Was spricht denn dagegen, sich per INOTIFY-Schnittstelle an die /etc/passwd zu hängen und dann auf die Änderungen zu reagieren?

Mit passenden BusyBox-Applets (es gibt ein inotifyd mit folgender "Hilfe":

~ # busybox inotifyd
BusyBox v1.27.2 multi-call binary.

Usage: inotifyd PROG FILE1[:MASK]...

Run PROG on filesystem changes.
When a filesystem event matching MASK occurs on FILEn,
PROG ACTUAL_EVENTS FILEn [SUBFILE] is run.
If PROG is -, events are sent to stdout.
Events:
        a       File is accessed
        c       File is modified
        e       Metadata changed
        w       Writable file is closed
        0       Unwritable file is closed
        r       File is opened
        D       File is deleted
        M       File is moved
        u       Backing fs is unmounted
        o       Event queue overflowed
        x       File can't be watched anymore
If watching a directory:
        y       Subfile is moved into dir
        m       Subfile is moved out of dir
        n       Subfile is created
        d       Subfile is deleted

inotifyd waits for PROG to exit.
When x event happens for all FILEs, inotifyd exits.
~ #

- wenn man es einbauen läßt in die BusyBox) kann man sich ja - praktisch ohne Aufwand - erst mal schlau machen, wie die Abläufe beim Schreiben einer neuen /etc/passwd durch den ctlmgr eigentlich aussehen:

~ # busybox inotifyd - /etc/passwd
Apr  1 01:41:03 ctlmgr[2448]: WLANLIB: _wcsi_daemon_select:206: Select failed, reason: 4(Interrupted system call)
Apr  1 01:41:37 ctlmgr[2448]: [box_users.cpp:2318] My_TransactionCommitVerify(): boxuser 11 was not changed.
Apr  1 01:41:37 ctlmgr[2448]: [box_users.cpp:2318] My_TransactionCommitVerify(): boxuser 12 was not changed.
Apr  1 01:41:37 ctlmgr[2448]: [box_users.cpp:2318] My_TransactionCommitVerify(): boxuser 98 was not changed.
Apr  1 01:41:37 ctlmgr[2448]: [box_users.cpp:2318] My_TransactionCommitVerify(): boxuser 10 was not changed.
Apr  1 01:41:37 ctlmgr[2448]: [box_users.cpp:2318] My_TransactionCommitVerify(): boxuser 0 was changed.
r       /etc/passwd
a       /etc/passwd
0       /etc/passwd
e       /etc/passwd
D       /etc/passwd
x       /etc/passwd
~ #

- hier wurde von mir ein weiterer Benutzer mit dem AVM-GUI hinzugefügt.

Jetzt kann man sich also aussuchen, welches Skript (denn PROG kann auch einfach ein Shell-Skript sein) man da an welches Ereignis knüpfen will ... an sinnvollsten ist da wohl sogar das x, denn das dürfte hier den erfolgreichen Abschluß des Umbenennens anzeigen und notfalls baut man am Anfang seiner Reaktion (falls das Event tatsächlich zu einem Zeitpunkt auftritt, wo die neue Datei noch nicht verfügbar ist, obwohl die Kernel-Funktion zum Umbenennen eigentlich "atomar" sein soll: https://man7.org/linux/man-pages/man2/rename.2.html ... aber man weiß (ohne Recherche/Test) nicht, wie das Umbenennen da tatsächlich abläuft) noch einen kurzen Stop mit ein, damit sich das "settlen" kann.

Aber dafür braucht man (ziemlich sicher) keine spezielle "preloaded library", die sich in den Syscall einklinkt und den umbiegt ... es spricht - soweit ich das sehe jedenfalls - ja nichts dagegen, wenn man erst nach dem Event selbst tätig wird und die nunmehr fehlenden Freetz-Benutzer noch einmal einträgt, bevor man dann die "finale Version" wieder sichert. Das kann durchaus "danach" erfolgen und muß nicht zwingend "stattdessen" sein ... notfalls stoppt man die betroffenen Dienste (die auf die Freetz-Accounts angewiesen sind) schon direkt beim x-Event und läßt sie erst wieder von der Leine, wenn man die /etc/passwd selbst noch einmal korrigiert hat.

Dafür braucht man also auch keine C-Kenntnisse und/oder einen Compiler ... mit den passenden BusyBox-Applets (die man dann allerdings einbauen lassen muß) und den passenden Kernel-Optionen (wobei INOTIFY auch bei AVM eigentlich immer dabei war/ist, denn deren NAS-Indizieren braucht(e) das auch) klappt das problemlos auch alles in Shell - also keine "Ausreden" denkbar, daß man dafür unbedingt einen "richtigen Programmierer" bräuchte (wobei auch Shell-Programmierung anspruchsvoll sein (oder werden) kann).

 

[hermann72pb]

inotify ist eine gute Idee! Ich nutze es auf diversen Linux-Systemen von Raspberry Pi bis zu den Servern für unterschiedliche Aufgaben. Allerdings waren es bei mir bis jetzt "richtige" bzw. "große" Systeme mit dem vollständigen inotify-Package (alles debian-basiert). busybox-Variante davon kannte ich bis jetzt nicht. Was ich mich in dem Zusammenhang immer gefragt hatte: Wieviel Ressorcen braucht so ein inotifyd zum Überwachen? Für meine Anwendungsfälle auf meinen Systemen hatte es bis jetzt gereicht, im Falle einer FritzBox sollte man es aber im Betrieb anschauen. Es hört sich zunächst bei einer gezielten Überwachung einer einzigen konkreten Datei nach nicht so viel an, darum sollte man es auf jeden Fall ausprobieren. Und viel Aufwand ist es echt nicht zu coden, wie Peter es schon richtig schreibt. Das kann ich von meinen Fällen bestätigen.
Interessant wäre aber zu wissen, ob jemand schon inotyfy auf der FritzBox dauerhaft eingesetzt hatte und hier über positive Erfahrungen im Dauerbetrieb berichten könnte.

 

[PeterPawn]

Ich hatte das inotifyd-Applet selbst eine Weile in Benutzung: https://github.com/PeterPawn/YourFritz/blob/master/customconfig/bin/custom_config/monitor - es diente mir zur Überwachung der Konfiguration zusätzlicher Pakete, wo die geänderten Einstellungen nach einem "Countdown" (um die Anzahl der Schreibzugriffe zu verringern und aufeinanderfolgende Änderungen zusammenzufassen) dann schließlich gesichert wurden für den nächsten Systemstart.

 

[Fox.Mulder]

@PeterPawn, vielen Dank für Deinen Hinweis auf inotifyd. Cuma/fda scheint gerade an einer Lösung mit inotifyd zu arbeiten.

 

[PeterPawn]

Macht er wohl ... ich habe das Repo ja auch selbst im Blick bzw. tausch(t)e mich mit @cuma (oder @fda77 in GitHub) bei anderen Gelegenheiten im dortigen Repo aus.

 

[Fox.Mulder]

Ich habe gerade die Änderungen von cuma/fda77 nachgetestet.

root@fritz:/var/mod/root# adduser test -G users -h /var/media/ftp
addgroup: can't find users in /etc/../var/tmp/gshadow
Changing password for test
New password:
Bad password: too short
Retype password:
passwd: password for test changed by root

root@fritz:/var/mod/root# inotifyd - /tmp
r       /tmp    group
a       /tmp    group
0       /tmp    group
r       /tmp    passwd
a       /tmp    passwd
0       /tmp    passwd
r       /tmp    passwd
a       /tmp    passwd
0       /tmp    passwd
r       /tmp    passwd
n       /tmp    passwd+
r       /tmp    passwd+
e       /tmp    passwd+
n       /tmp    passwd-
a       /tmp    passwd
c       /tmp    passwd+
w       /tmp    passwd+
m       /tmp    passwd+
y       /tmp    passwd
w       /tmp    passwd
r       /tmp    shadow
n       /tmp    shadow+
r       /tmp    shadow+
e       /tmp    shadow+
e       /tmp    shadow+
n       /tmp    shadow-
a       /tmp    shadow
c       /tmp    shadow+
w       /tmp    shadow+
m       /tmp    shadow+
y       /tmp    shadow
w       /tmp    shadow
r       /tmp    passwd
a       /tmp    passwd
0       /tmp    passwd
r       /tmp    group
a       /tmp    group
0       /tmp    group
r       /tmp    group
n       /tmp    group+
r       /tmp    group+
e       /tmp    group+
e       /tmp    group+
n       /tmp    group-
a       /tmp    group
c       /tmp    group+
w       /tmp    group+
m       /tmp    group+
y       /tmp    group
w       /tmp    group
r       /tmp    gshadow
n       /tmp    gshadow+
r       /tmp    gshadow+
e       /tmp    gshadow+
e       /tmp    gshadow+
n       /tmp    gshadow-
a       /tmp    gshadow
c       /tmp    gshadow+
w       /tmp    gshadow+
m       /tmp    gshadow+
y       /tmp    gshadow
w       /tmp    gshadow
r       /tmp    passwd
a       /tmp    passwd
0       /tmp    passwd
r       /tmp    passwd
a       /tmp    passwd
0       /tmp    passwd
r       /tmp    shadow
a       /tmp    shadow
0       /tmp    shadow
r       /tmp    shadow
n       /tmp    shadow+
r       /tmp    shadow+
e       /tmp    shadow+
d       /tmp    shadow-
n       /tmp    shadow-
a       /tmp    shadow
c       /tmp    shadow+
w       /tmp    shadow+
m       /tmp    shadow+
y       /tmp    shadow
w       /tmp    shadow
r       /tmp    passwd
n       /tmp    passwd+
r       /tmp    passwd+
e       /tmp    passwd+
e       /tmp    passwd+
d       /tmp    passwd-
n       /tmp    passwd-
a       /tmp    passwd
c       /tmp    passwd+
w       /tmp    passwd+
m       /tmp    passwd+
y       /tmp    passwd
w       /tmp    passwd
r       /tmp    passwd
a       /tmp    passwd
0       /tmp    passwd
n       /tmp    passwd.mod
r       /tmp    passwd.mod
w       /tmp    passwd.mod
e       /tmp    passwd.mod
c       /tmp    passwd.mod
r       /tmp    passwd.mod
r       /tmp    passwd
a       /tmp    passwd
c       /tmp    passwd.mod
0       /tmp    passwd
w       /tmp    passwd.mod
e       /tmp    passwd
e       /tmp    passwd
c       /tmp    passwd.mod
r       /tmp    passwd.mod
c       /tmp    passwd.mod
w       /tmp    passwd.mod
e       /tmp    group
e       /tmp    group
c       /tmp    group
r       /tmp    group
c       /tmp    group
w       /tmp    group
e       /tmp    shadow
e       /tmp    shadow
c       /tmp    shadow
r       /tmp    shadow
c       /tmp    shadow
w       /tmp    shadow
e       /tmp    gshadow
e       /tmp    gshadow
c       /tmp    gshadow
r       /tmp    gshadow
c       /tmp    gshadow
w       /tmp    gshadow
r       /tmp    passwd.mod
a       /tmp    passwd.mod
0       /tmp    passwd.mod
r       /tmp    passwd.mod
a       /tmp    passwd.mod
0       /tmp    passwd.mod
r       /tmp    passwd.mod
a       /tmp    passwd.mod
0       /tmp    passwd.mod
r       /tmp    group
a       /tmp    group
0       /tmp    group
r       /tmp    group
a       /tmp    group
0       /tmp    group
r       /tmp    group
a       /tmp    group
0       /tmp    group
r       /tmp    group
a       /tmp    group
0       /tmp    group
r       /tmp    group
a       /tmp    group
0       /tmp    group
r       /tmp    group
a       /tmp    group
0       /tmp    group
r       /tmp    passwd
n       /tmp    passwd.tmp
r       /tmp    passwd.tmp
a       /tmp    passwd
c       /tmp    passwd.tmp
w       /tmp    passwd.tmp
0       /tmp    passwd
e       /tmp    passwd.tmp
r       /tmp    passwd.mod
r       /tmp    passwd.tmp
a       /tmp    passwd.tmp
0       /tmp    passwd.tmp
c       /tmp    passwd.mod
w       /tmp    passwd.mod
r       /tmp    passwd.mod
a       /tmp    passwd.mod
0       /tmp    passwd.mod
d       /tmp    passwd.tmp
m       /tmp    passwd.mod
y       /tmp    passwd
e       /tmp    .usersloaded

root@fritz:/var/mod/root# cat /etc/passwd
asec::101:101::/nonexistent:/noshell
bittorrent:x:104:80:bittorrent:/home/bittorrent:/bin/false
ftp:x:105:80:ftp:/home/ftp:/bin/false
nobody:x:102:1000:nobody:/home/nobody:/bin/false
root:x:0:0:root:/mod/root:/bin/sh
smb::100:100::/nonexistent:/noshell
ftpuser:x:103:80:ftpuser:/var/media/ftp:/bin/false
boxusr31:...

root@fritz:/var/mod/root# cat /etc/group
asec::101:asec,smb
nas::3:asec
nobody:x:1000:nobody
root:x:0:
smb::100:smb
users:x:80:ftpuser,bittorrent,ftp
watchdog::1:smb,asec

root@fritz:/var/mod/root# cat /etc/shadow
bittorrent:!:0:0:99999:7:::
ftp:!:0:0:99999:7:::
nobody:!:0:0:99999:7:::
root:???????????:18644:0:99999:7:::

Der neu angelegte Benutzer test ist in /etc/passwd, /etc/group und /etc/shadow nicht vorhanden.

 

[hermann72pb]

@Fox.Mulder: Ich habe nicht ganz verstanden, wozu du "inotifyd" auf das ganze /tmp da gestartet hast. Und vor allem, was ist da alles in der Zwischenzeit passiert, als inotifyd da diese Statusmeldungen ausgespuckt hatte. Kamen sie da alle auf einmal oder erst nach und nach? Ich glaube, Peter hatte es hier mit der Kommandozeile lediglich gezeigt, wie es prinzipiell geht, der Sinn der Sache ist aber, dass man inotifyd im Vorfeld startet und dem auch sagt, was es zu machen und zu tun hat, wenn ein Ereignis auftritt. Ob cuma das alles schon fertig im repo hat, weiß ich nicht. Ja, er hatte da Einiges bereits eingebaut, was in die Richtung geht, aber ob es schon endgültig vollbracht ist... Bei seiner spezifischen Art und Weise, wie cuma es in die repo eincheckt (sehr verteilt über mehrere commits), ist es für einen Außenstehenden nur sehr schwer nachvollziehbar, ob es bereits fertig ist oder nicht.
Ich hatte es in meinen Skripten damals etwas anders gelöst. Mag sein, dass ich inotyfyd an sich nicht kannte oder es zu dem Zeitpunkt nicht gab. Ich hatte mir aber damals meinen Daemon selbst zurecht gebastelt:

#! /bin/sh
# Initify Daemon
DIRTOWATCH="/dir/to/watch/"
UPDATEBIN="/usr/local/bin/update_script.sh"
[ -n "$1" ] && DIRTOWATCH="$1"
[ -n "$2" ] && UPDATE_BIN="$2"
while true; do inotifywait -qq -e close_write ${DIRTOWATCH} && ${UPDATEBIN}; done &
exit 0

Dazu gibt auch noch rc.script und das eigentliche update_script.sh von mir. Aber vermutlich kann der inotifyd das alles heutzutage schon alleine und ohne diese ewige Warteschleife im Shell.

 

[Fox.Mulder]

@hermann72pb: Die angegebenen Logeinträge auf Dateien in /tmp) erfolgen während des Anlegens des Benutzers test. Ich hatte davor versucht, nur Zugriffe auf /tmp/passwd zu sehen, war damit aber nicht zufrieden. Parallel läuft noch ein inotifyd Prozess auf /tmp/passwd.

 

[hermann72pb]

Wie gesagt, ich kenne und nutze nur diese alte Methode mit meinem eigenen selbstgebastelten daemon (s. oben). Aber dort weiß ich zumindest, wie es geht. In meinem Fall wartet "inotifywait" solange, bis im vordefinierten Verzeichnis ${DIRTOWATCH} eine Datei geschrieben und daraufhin geschlossen wurde "close_write". Wenn es erfolgreich war (s. &&), dann läuft mein ${UPDATEBIN}-Skript und dann geht das alles per endlos "while" von vorne wieder. Auch, wenn inotify crashen sollte (zumindest so war meine Idee).
rc.script rumherum habe ich extra geschrieben (ist in dem Falle debian-artig), um dieses endlose Dasein von inotify da bequem starten, stoppen und abfragen zu können, ob es noch läuft.
In dem, was cuma da eingecheckt hat, finde ich irgendwie genau diese Aktion nicht, was bei mir ${UPDATEBIN} tut. Es kann natürlich sein, dass ich zu doof bin und es bei "inotifyd" irgendwie anders behandelt wird, als mit meinem klassischen "inotifywait".
Ferner weiß ich nicht, ob es eine gute Idee ist, mehrere Instanzen vom inotifyd da auf ähnliche Ziele (Verzeichnis vs. Datei in dem Verzeichnis) parallel laufen zu lassen, was du mit deinem separaten (und zusätzlichem zu cumas eigens programmierten) Aufruf von inotifyd ja tust. Der Hund wird irgendwo in der Implementierung von cuma begraben sein, die vermutlich noch nicht ganz fertig ist und darum bei dir gänzlich oder partiell nicht funktioniert.
Ich würde da echt damit etwas abwarten oder cuma direkt fragen, was da los ist. Oder alternativ die Implementierung von cuma anpassen und damit experimentieren. Aber dann betreibt ihr eine Parallelentwicklung, was vermutlich auch nicht besonders produktiv ist.

Edit: Hier ist übrigens manpage vom klassischen inotify, wie ich es kenne: https://wiki.ubuntuusers.de/inotify/
Ist aber in dem Falle debian-lastig und wird vermutlich nicht auf besondere Vorliebe von Peter stoßen. Der "inotifyd" von busybox ist vermutlich etwas spartanischer ausgeführt, wie alles in busybox. Dennoch kann man es vermutlich auch einsetzen, wenn man es richtig tut. Peter hatte übrigens in seinem Beispiel auch eine ähnliche Vorgehensweise, wie bei mir mit dem "immer wieder anstoßen" von inotifyd. Denn obwohl das Ding sich Daemon nennt, heißt es noch nicht, dass es unendlich läuft. Bei "x" terminiert inotifyd und soll daher neu angestoßen werden (s. Beispiel von Peter oder meine while-Schleife oder Beispiele von der manpage).

 

[PeterPawn]

Das Applet gibt es noch nicht sooo lange in der BusyBox - zuvor war die Benutzung von inotifywait noch nachvollziehbar, aber mittlerweile wäre das ein weiteres Paket (inotify-tools), während es bei der BusyBox nur ein weiteres Applet ist.

Außerdem ist das Applet dahingehend "smarter", daß da nicht bei jedem Event Prozesse neu initialisiert werden müssen (zumindest nicht für die Überwachung, für die Behandlung des Events (also Dein $UPDATEBIN) natürlich schon). Wobei das inotifywait auch anders arbeiten könnte (mit passenden Optionen wie --monitor), als das bei Dir der Fall ist - da wird ja auch nach jedem Event das inotifywait beendet und muß danach neu gestartet werden - was dann auch jedesmal mit dem Abräumen der Event-Handler und dem Neuaufsetzen dieser Handler (im Kernel) verbunden ist. Ohne dieses Beenden bleiben die (Inode-basierten) Handler einfach weiter aktiv - nur die ausgegebenen Nachrichten zu den Events müssen dann halt "verarbeitet" werden, was aber mit einem FIFO auch kein Problem ist, selbst wenn das Programm weiter läuft.

Beim BusyBox-Applet werden so eben immer weiter Events ausgelesen und behandelt, bis alle überwachten Dateien nicht länger existieren (oder der Prozess gekillt wird). @cuma nutzt das Applet nur "ungewöhnlich", indem nur eine einzelne Datei überwacht wird und erst wenn für diese dann ein x-Event (Datei kann nicht länger überwacht werden) signalisiert wurde und sich der Daemon daraufhin beendet (weil's nichts mehr zu überwachen gilt), dann erfolgt auch die "Behandlung" dieses Ereignisses.

Das führt dann halt auch dazu, daß alle anderen Änderungen an der /var/tmp/passwd, die nicht über das Neuschreiben und Umbenennen im ctlmgr erfolgen (und wo dann der vorhandene Inode weiterhin existiert), von dieser Art der Überwachung gar nicht erkannt werden KÖNNEN ... jedenfalls nicht so, wie das jetzt implementiert wurde.

Schlauer wäre es vermutlich wirklich, wenn man tatsächlich x und w (das ist ja Dein "close_write") überwacht (nach x muß man dann halt auch das Applet neu starten, nach w nicht) und damit sowohl die Aktionen des ctlmgr mitbekommt, als auch Änderungen durch andere Programme wie adduser oder passwd - zumindest müßte der Freetz-NG-Benutzer dann nicht länger nach jeder dieser Änderungen das Sichern von Hand anwerfen (modsave).

Wobei ich mir bei meiner Lösung (mit dem Verzögern der Reaktionen durch einen Countdown) schon etwas gedacht hatte ... denn manchmal gibt es auch mehrere Änderungen kurz nacheinander (und da meine ich nicht mal mehrere Aufrufe von adduser von Hand, sondern auch automatisierte Abläufe) und es wäre Unsinn, dann für jede einzelne davon das Ergebnis in den Freetz-Settings zu sichern. Erst dann, wenn die neuen Daten eine gewisse "Stabilität" erlangt haben, kann man die (beim w-Event, denn x müßte man schneller behandeln) sinnvoll (und "mit Perspektive") sichern.

EDIT: Es schadet - nebenbei - auch nichts, wenn man mehrere Watcher für eine Datei hat; die kriegen alle ihr eigenes Event und sollten - ab da, wo es ins "Userland" geht - auch parallel ihre Behandlungen machen können.

 

[Fox.Mulder]

Schlauer wäre es vermutlich wirklich, wenn man tatsächlich x und w (das ist ja Dein "close_write") überwacht (nach x muß man dann halt auch das Applet neu starten, nach w nicht) und damit sowohl die Aktionen des ctlmgr mitbekommt, als auch Änderungen durch andere Programme wie adduser oder passwd - zumindest müßte der Freetz-NG-Benutzer dann nicht länger nach jeder dieser Änderungen das Sichern von Hand anwerfen (modsave).

Wenn dies nach jeder Aktion des ctlmgr zum Schreiben ins Flash führt, würde man ggf. einen wesentlich schnelleren wear out des Flashs provozieren.

 

[Fox.Mulder]

Eigentlich wollte ich meinen Kommentar in https://github.com/Freetz-NG/freetz-ng/commit/4d7bd9c526c8926864337bc8c44e9f56eeb3cc76 schreiben. Aber Cuma/Fda77 hat meine beiden Git-Accounts für den Freetz-NG Git gesperrt!

Folgende Zeile von fda's /usr/bin/modpasswd muss geändert werden:

nohup modusers load 0</dev/null &>/dev/null &

in:

nohup modusers update 0</dev/null &>/dev/null &

Grund: Mit modusers load wird der letzten Stand aus /tmp/flash/users wieder hergestellt und zwischenzeitliche Änderungen gehen verloren. Mit modusers update werden zuerst die Dateien in /tmp/flash/users aktualisiert. Dadurch werden neu angelegte Benutzer berücksichtigt.

 

[PeterPawn]

würde man ggf. einen wesentlich schnelleren wear out des Flashs provozieren.

Verstehe ich nicht ... das würde bei x ja nur nach jedem "Umbenennen" der neuen Datei des ctlmgr (die damit die alte ersetzt) erfolgen und das war schon immer so.

Neu wäre lediglich, daß auch solche Dinge wie Deine Tests oben bei einem positiven Ergebnis (und einem close() nach dem Schreiben von Daten - wenn ein Kommando fehlerhaft ist, wird die Datei auch nicht geändert) gesichert werden ... und obendrein schrieb ich sogar noch, daß ich mir bei dem "Countdown", der nach einem solchen Event startet und beim Erreichen von Null dann die Sicherung ausführt, schon etwas gedacht hatte. Der startet natürlich auch bei jedem weiteren Schreibzugriff neu, wenn er noch nicht bei Null angekommen war - daher würde so etwas die Anzahl der Schreibzugriffe (auf den Flash) sogar noch verringern.

Und was ist denn "jede Aktion des ctlmgr" bei Dir? Der macht gar nichts anderes mit dieser Datei, als sie bei Änderungen neu - unter einem anderen Namen - zu generieren (das geht vom Hinzufügen/Ändern/Löschen eines (AVM-)Benutzers bis zum Ändern eines Kennworts (für einen AVM-Benutzer) - andere "Aktionen" gibt es dort für die fragliche Datei gar nicht) und anschließend diese neue Datei umzubenennen (womit die alte dann gelöscht wird, was zum x-Event in inotifyd führt).

Alles andere interessiert den ctlmgr gar nicht ... ob Du da ein passwd oder ein adduser aufrufst oder nicht - alles das führt derzeit nicht einmal zu irgendeinem "Zucken" des ctlmgr und damit erkennt die "Überwachung" weder in der alten Version (mit libctlmgr), noch in der neuen mit inotifyd überhaupt, daß es da einen Schreibzugriff gab und Daten geändert wurden. Daher muß der Benutzer das manuell "ansagen" ... und genau das KÖNNTE man (was etwas vollkommen anderes ist als MÜSSTE) zusätzlich implementieren, wenn man dem Nutzer genug Intelligenz zutraut, daß der keine unnötigen Schreiboperationen an dieser Datei ausführt (und dann - bisher - auf das modsave verzichtet hat, denn ansonsten ist das ja immer noch dieselbe Anzahl von Sicherungen). Meinetwegen kann man das sogar noch "einstellbar" machen, ob eine automatische Sicherung solcher Änderungen an der /var/tmp/passwd erfolgen soll oder nicht ... wobei man dann auch die /var/tmp/shadow einbeziehen sollte, denn sonst wird nach einem passwd-Kommando doch nicht automatisch gesichert, wenn das Schreiben in die Shadow-Datei erfolgte.

Ich blicke aber da auch gar nicht durch, was Du in #8 getestet hast, weil ich nicht verstehe, wieso man erst ein adduser machen sollte und DANACH dann mit inotifyd schaut, welche Zugriffe auf die Dateien danach noch erfolgen. Sollte man das nicht gleich von Beginn an überwachen/aufzeichnen? Nur so kann man ja erkennen, ob da nach Deinem adduser noch weitere Zugriffe erfolgen, die den (vermeintlich/vermutlich erfolgreich hinzugefügten) Benutzer dann wieder entfernen könnten.

Normalerweise sollte (Stand 128cdf7 - und es macht absolut auch Sinn, wenn Du selbst den Hash des Checkouts immer mit dazu schreibst, denn manchmal committed @cuma schneller, als Lucky Luke ziehen kann) da ohne einen expliziten Aufruf von modusers save (was die Daten auch erst mal nach /tmp/flash/users schafft und noch gar nichts in den Flash schreibt - das erfolgt erst beim modsave flash) gar nichts weiter geändert werden ... daher ist es auch vollkommen unklar, wie es zu den "überwachten" (Schreib-)Zugriffen auf eine /tmp/passwd.mod kommen kann, die eigentlich nur von modusers genutzt wird (https://github.com/Freetz-NG/freetz...3a8d/make/mod/files/root/usr/bin/modusers#L16).

Was soll denn bei den Kommandos, die Du uns in Deinem Test zeigst, jetzt das modusers load getriggert haben? Das neue modpasswd (https://github.com/Freetz-NG/freetz...576/make/mod/files/root/usr/bin/modpasswd#L23) dürfte es eigentlich nicht gewesen sein - das sollte nur dann modusers load aufrufen, wenn die alte Datei umbenannt/gelöscht wurde und das dürfte weder bei Deinem adduser noch bei passwd passiert sein.

Denn die BusyBox arbeitet da beim Schreiben einer neuen passwd-Datei anders: https://git.busybox.net/busybox/tree/libbb/update_passwd.c#n86 - zuerst wird ein event. vorhandenes altes Backup (mit einem - am Ende des Namens) gelöscht, danach ein Hardlink(!) auf den alten Inhalt angelegt (damit bleibt der Inode erhalten, auch wenn die Datei beim Umbenennen gelöscht wird) und dann der Inhalt der neuen Datei unter einem neuen Namen (mit + am Ende) geschrieben. Die wird danach dann umbenannt und ersetzt mit dieser Aktion dann die alte Version - die aber weiterhin existiert, daher gibt es da auch kein x. Das macht es so einfach, zwischen Änderungen durch den ctlmgr und Änderungen durch andere Kommandos (der BusyBox) zu unterscheiden.

EDIT: Wobei man dann auch die Behandlung so machen muß, daß es nicht zu zweimaligen Änderungen durch Applets kommt - denn beim zweiten Mal würde der Inode vom ersten Mal (der dann ja schon das Backup ist) ebenfalls gelöscht und es gäbe ein "no more watching possible". Aber mit dem bereits zweimal angesprochenen Countdown fängt man auch diese Situation genauso gekonnt ab - man muß nur "mitschreiben", welchen Namen die gelöschte Datei zuletzt hatte (bei den Applets wäre es dann der Name mit dem Minus am Ende), damit man nach Änderungen durch den ctlmgr die Freetz-Accounts so schnell wie möglich wieder hinzufügt und nicht erst, wenn der Countdown runtergezählt wurde.

---

Und es tut mir ja leid, aber #14 ist - beim oben angegebenen Stand - einfach auch Quatsch. Das nohup würde/soll nur dann aufgerufen werden, wenn der ctlmgr die alte /etc/passwd (unter dem Symlink auf /var/tmp/passwd) schon durch seine neu erzeugte Datei (die zuvor /var/tmp/passwd.tmp hieß) ersetzt HAT, indem er die neue Datei in den alten Namen umbenannt hat.

Wie sollte es zu diesem Zeitpunkt dann helfen können, wenn man ein modusers update aufruft, wenn die gerade jetzt existierende /var/tmp/passwd doch die Freetz-Konten gar nicht (mehr) enthält? Da hast Du die Abläufe (die ich oben versucht habe zu erklären) einfach nicht verstanden ... genauso wenig, wie ich Deine Tests.

Wenn das so implementiert ist, wie derzeit, dann braucht es eben genau die oben angegebenen Kommandos (modusers + modsave) und für deren Eingabe/Ausführung ist dann der Benutzer zuständig. Die Zeile mit dem nohup ist nur dann wirksam, wenn der ctlmgr selbst eine neue Datei geschrieben hat und da sind NIEMALS die Freetz-Konten enthalten und ebenso keine einzige Änderung, die man mit irgendwelchen BusyBox-Applets (wie in Deinem Test) vorgenommen hat.

---

 

[Fox.Mulder]

Mit modusers load funktioniert folgender Ablauf nicht:

root@fritz:/var/mod/root# adduser test
Changing password for test
New password:
Bad password: too short
Retype password:
passwd: password for test changed by root
root@fritz:/var/mod/root# cat /tmp/passwd
asec::101:101::/nonexistent:/noshell
bittorrent:x:104:80:bittorrent:/home/bittorrent:/bin/false
ftp:x:105:80:ftp:/home/ftp:/bin/false
nobody:x:102:1000:nobody:/home/nobody:/bin/false
root:x:0:0:root:/mod/root:/bin/sh
smb::100:100::/nonexistent:/noshell
ftpuser:x:103:80:ftpuser:/var/media/ftp:/bin/false
boxusr31:...

Der neu angelegte Benutzer test ist unmittelbar nach adduser nicht in /tmp/passwd enthalten. D.h., dass modusers load von inotifyd ausgeführt wurde und dadurch der neue Benutzer gleich wieder gelöscht wurde. Bisher wurde in libctlmgr ebenfalls modusers update aufgerufen, allerdings nur durch den ctlmgr und nicht durch andere Aktionen. Nun führen wohl auch andere Aktionen, wie adduser zur Aktivierung der Aktion durch inotifyd.

Ich habe mir gerade modusers angesehen und komme wieder zum Ergebnis, dass modusers update in modpasswd aufgerufen werden muss, wie bisher in libctlmgr und nicht modusers load. Das hat auch den Vorteil, dass modusers save nicht mehr manuell nach adduser aufgerufen werden muss.

 

[hermann72pb]

ach, jetzt habe ich es verstanden, Peter mit dem "x" und deiner Kritik an cuma und seiner Antwort auf github... Es ist echt schwer auf mehreren Platformen es gleichzeitig zu verfolgen, geschweige schnellen commits von cuma gedanklich zu folgen. Ich versuche es mit eigenen Worten kurz zusammenzufassen:
1. Die erste Implementierung von cuma mit inotifyd ist zwar von der Implementierung her etwas gewöhnungsbedürftig (sagen wir mal unklassisch), von der Logik her sollte sie aber funktionsfähig sein und das alte Verhalten vollständig nachbilden
2. Eine "saubere" Implementierung, die du empfehlen würdest ist quasi "nice to have" und vor allem ganz gut für einen weiteren Ausbau. Zudem würde sie sich für alle anderen außer cuma später wahrscheinlich leichter zu lesen und zu verstehen sein
3. Events "x" und "w" könnte man später separieren und somit erkennen, woher die Änderung kommt (wenn man es denn braucht), da ctlmgr und adduser die Dateien unterschiedlich behandeln
4. "modsave" könnte man dann auch mintegrieren, bedarf aber einer intelligenten Behandlung und evtl. ein zeitversetztes Abspeichern im Flash

 

[PeterPawn]

Die Ergänzung oben im ersten Abschnitt erklärt dann aber auch wieder, warum es beim Test von @Fox.Mulder trotzdem zum "Event" in modpasswd kam - das war schlicht der zweite Aufruf von update_passwd() in der libbb der BusyBox und damit wurde dann die ursprünglich überwachte Datei (die zwischendrin als Backup weiter existierte) doch noch gelöscht - was wieder zum x-Event führt. Da muß man die Überwachung dann doch "noch smarter" implementieren ... ein Beispiel (Überwachen des ersten Umbenennens) habe ich oben schon genannt. So, wie es jetzt in Freetz-NG implementiert ist, funktioniert es zwar auch, aber nur so lange, wie man die Datei NICHT mit anderen BusyBox-Applets ändert (und dann ist das zweimalige Ändern fast unvermeidlich, weil auch ein adduser intern ein passwd aufrufen würde).

 

[PeterPawn]

Mir geht das auch auf die Eier, daß dieses Thema jetzt ständig an zwei verschiedenen Stellen diskutiert werden muß, weil @cuma nicht mehr im IPPF schreiben will und @Fox.Mulder nicht mehr im Freetz-NG-Repo schreiben darf.

Und da ist es mir auch vollkommen egal, was da wer für Gründe hat - nach dem, was ich so mitbekommen habe, hat da tatsächlich JEDER seinen Anteil dran. Wer's nicht glauben mag, kann ja mal hier: https://github.com/Freetz-NG/freetz-ng/discussions/182 in den "eingeklappten" Beiträgen nachlesen - wobei @CommanderAdama wohl ein Synonym von @Fox.Mulder und damit einer der weiter oben angesprochenden Accounts ist.

Leute ... könntet Ihr bitte einfach mal erwachsen werden und Euch mehr "um die Sache" kümmern, als immer nur um Eure eigenen "Befindlichkeiten"?

Ich brauche kein

Aber Cuma/Fda77 hat meine beiden Git-Accounts für den Freetz-NG Git gesperrt!

in fett und rot und ich brauche auch niemanden, der hier im IPPF durch alle Threads wandern möchte und dabei nach "bösen Wörtern" suchen will und dann auch noch ansagt als Absicht, das dann "alles zu melden", anstatt nur (in der Diskussion mit demjenigen, der da - vielleicht auch in Überreaktion - ein "verarschen" bemängelt hat als Moderator) Beispiele für andere Beiträge in dieser Richtung zu liefern.

Irgendwie artet das alles immer mehr in "Kindergarten" aus ("Hab' ich gar nich'" - "Doch, hast Du ..." - "Nein, stimmt nicht." - "Hast Du wohl ..." ... fehlt nur noch das "Dann geh doch zu Netto.")... und auf der Strecke bleibt dabei das Projekt und dessen (potentielle) Benutzer.

Die haben ohnehin nur noch die Wahl zwischen Pest und Cholera ... da, wo früher Freetz sich praktisch nie bewegt hat, wenn eine Idee nicht von @er13 stammte oder für ihn selbst "verwendbar" schien (da gab es überwiegend auch nur die "Verwaltung" des Status Quo mit Updates von Paketen auf neue Versionen), ist es heutzutage bei Freetz-NG schwierig, überhaupt mal einen "reproduzierbaren" Stand zu erhalten, wenn man (gemeinsam) nach Problemen suchen will.

Da, wo sich Freetz wie Blei verhielt und schwer und träge war, ist Freetz-NG wie Quecksilber und man weiß als Freetz-NG-Benutzer nie genau, ob die letzten Änderungen nicht doch wieder ein (neues, altes, irgendeins) Problem einschleppen, mit dem man dann erst wieder kämpfen muß, bevor man zu seinem Image kommt und zu dem, was man damit eigentlich machen wollte.

Das, was der "normale" Freetz-(NG-)Benutzer aber eigentlich bräuchte, ist ein Projekt, was einerseits die neuen AVM-Versionen unterstützt und andererseits trotzdem so stabil ist (und nur vorsichtig und nach entsprechenden Tests "für alle" geändert wird), daß man sich auch auf einen erfolgreichen Build VERLASSEN kann und nicht immer nur erleichtert sein muß, wenn der Build funktioniert und obendrein das Image dann auf der Box auch noch das macht, was es soll. Aus dem Beamten-Dreisatz bei Freetz wurde der Hollywood-Klassiker "Planlos in Seattle" ... stellt sich nur die Frage, wer jetzt Meg Ryan ersetzen soll.

 

[Cataclysm_177]

Das cuma hier nicht mehr schreibt hat andere gründe der User "forenuser" pardon "Fox.Mulder" ist daran nicht schult.