Benutzerverwaltung: ftp und samba mehrfach/nicht gefunden

[cuma]

Hier hab ich das auch schon beschrieben:  http://www.ip-phone-forum.de/showthread.php?t=159675

Im Log erscheint bei jedem booten:
* Looking for user 'ftp' … created - now saving to data buffer … done
* Looking for user 'samba' … adduser: /home/samba: File exists

in der Datei "shadow" erscheinen die Benutzer aber in der Anzahl der Neustarts:
- root:xxxxxxxxxxxxxxgehaimxxxxxxxxxx:12332:0:99999:7:::
- ftp:!:13919:0:99999:7:::
- samba:!:13919:0:99999:7:::
- ftp:!:13919:0:99999:7:::
- samba:!:13919:0:99999:7:::
- ftp:!:13919:0:99999:7:::
- samba:!:13919:0:99999:7:::
- ftp:!:13919:0:99999:7:::
- samba:!:13919:0:99999:7:::
- …

[cinereous]

Ist dieses Verhaltne in der aktuellen Revision noch nachvollziehbar? Oliver hat da nämlöiich an den Services etwas geändert. Bitte überprüf das mal.

[oliver]

Ich wüßte nicht, dass ich da was geändert hab. Natürlich wird im Moment kein Samba User von Freetz angelegt, da es kein Startskript mehr gibt.

[cinereous]

Darauf wollte ich hinaus. Du ersetzt den AVM-Samba inzwischen mit "unserem". Somit könnte es schon das Problem gelöst haben, muss aber nicht.

[cinereous]

Zumindest für den Sambauser natürlich nur

[ralf]

Kann es sein, daß irgendwo von AVM die Benutzer ftp und samba aus /etc/passwd entfernt werden?

Ich kann mich dunkel erinnern, daß die FTP Benutzer immer hinten in der /etc/passwd standen, was dafür spricht, daß diese aus der Datei entfernt und dann hinten angehängt werden.

Vor dem Anlegen eines neuen Benutzers wird nämlich überprüft, ob er schon in /etc/passwd steht. Die naheliegendste Erklärung ist daher, daß diese nur aus /etc/passwd entfernt werden und dann in /etc/passwd und /etc/shadow eingefügt werden.

Kann einer, bei dem das Problem auftritt, dies überprüfen?

[cuma]

Hallo,
ich hab mit "adduser xx" einen Benutzer angelegt und dann aus gshadow, group und passwd händisch gelöscht. Ein erneutes "adduser xx" fügt dann eine erneute Zeile mit xx in die shadow ein. Wenn ich mit "passwd xx" sein Passwort ändere, wird es allerdings in allein Zeilen der shadow geändert.
Ich hab auch noch viele anderes ausprobiert, aber die Boot-Meldung "Looking for user" habe ich nicht wegbekommen

[cuma]

Evtl noch wichtig: "ftpuser" wird nicht in der shadow angelegt und sein Passwort steht in der passwd

[Mulder]

Es werden alle Nutzer, welche angelegt wurden aus der passwd "automatisch" entfernt entweder, wenn ich eine Änderung des Passwortes von ftpuser in der AVM Oberfläche vornehme, oder bei einem Neustart aus der Datei /etc/passwd. Die Einträge in der shadow und group Datei bleiben erhalten. Den gleichen Nutzer kann man nicht mit adduser anlegen, solange entsprechende Einträge in shadow oder group enthalten sind. In /etc/passwd bleiben immer nur die Einträge für root und ftpuser erhalten. Manchmal ist bei mir noch der Nutzer ftp drin, aber dessen Einstellungen, z.B. ein geändertes home-Verzeichnis bleiben ebenfalls nicht erhalten. Scheint also so, als wenn es Funktionen gibt, welche den Inhalt der passwd Datei ändern, dabei aber keine Rücksicht auf zusätzlich angelegte Nutzer nehmen. Diese Funktionen werden vermutlich beim Systemstart bzw. Änderungen von ftpuser in der AVM Weboberfläche ausgeführt.

[ralf]

Wie schon  hier beschrieben, sieht es aus, als würde /usr/share/ctlmgr/libctlusb.so die Datei /etc/passwd ändern. Einige Strings aus der Datei:

ftpuser
/var/tmp/passwd.tmp
/etc/passwd
realpath of /etc/passwd failed

Es wird also anscheinend mit realpath gesucht, wohin der Link /etc/passwd zeigt und dann die Datei geändert. Ich habe Component daher auf AVM geändert, da das Problem letztlich von AVM verursacht wird.

Wenn die Datei nicht nur beim Booten, sondern auch bei anderen Änderungen zurückgesetzt wird, ist die einzige echte Lösung des Problems, die AVM Librray zu ändern. Leider wird das schwierig ohne die Quelltexte.

[oliver]

Ich habe das Verhalten näher untersucht und konnte feststellen, dass ein Neustart des ctlmgr alle Benutzer, außer root und ftpuser, aus der passwd löscht.

readlink("/etc", 0x7fd2a9f0, 4095)      = -1 EINVAL (Invalid argument)
readlink("/etc/passwd", "../var/tmp/passwd", 4095) = 17
readlink("/var", 0x7fd2a9f0, 4095)      = -1 EINVAL (Invalid argument)
readlink("/var/tmp", 0x7fd2a9f0, 4095)  = -1 EINVAL (Invalid argument)
readlink("/var/tmp/passwd", 0x7fd2a9f0, 4095) = -1 EINVAL (Invalid argument)
rename("/var/tmp/passwd.tmp", "/var/tmp/passwd") = 0

Das heißt, wir müssten einen anderen Namen für unsere passwd wählen, der nicht /etc/passwd ist? Und das müssten wir wo anpassen? uClibc, busybox? Auch im bftpd, vsftpd, drobear usw.?

[cuma]

Das hatte ich auch so überlegt, aber dann müssten doch alle Programme geändert werden, zB telnet, adduser, deluser, Dateisysteme mit Berechtigungen,…. Das scheint doch zu aufwendig.
Ist es möglich einen "Loader" zu Programmieren, der ctlmgr ersetzt, und bei Aufruf die passwd ins/vom Flash rettet und dann die Kontrolle an das Programm selbst übergibt? Das einzige Problem hierbei
ist, dass der ctlmgr nicht mit kill/killall beendet werden kann. Oder könnte dies auch abgefangen werden?

[cinereous]

Replying to cuma:

Ist es möglich einen "Loader" zu Programmieren, der ctlmgr ersetzt, und bei Aufruf die passwd ins/vom Flash rettet und dann die Kontrolle an das Programm selbst übergibt?

Das hatte ich gestern mit Oliver auch schon überlegt, inwiefern man einen Wrapper bauen kann, der den ctrlmgr ersetzt, die passwd irgendwohinverschiebt, die daten nach dem Start des ctrlmgr wieder an die passwd anhängt. Ich bin nur noch nicht dazu gekommen - und wie ich sehe - Oliver auch nicht, das zu testen.

LG

c.

[cinereous]

Obiger PAtch läuft bei mir seit einigen Tagen. Mit diesem hab ich seither keine neuen ntp und ftp-User. Denn diese waren es bei mir.

Der Patch macht letztendlich folgendes: den ctlmgr umbenennen, ein Script vorschlaten, dass die originale passwd wegschreibt. dann den ctlmgr aufruft und die Zeilen aus der originalen passwd wieder anfügt an die von ctlmgr veränderte. Scheint das zu tun, was sie soll.

Änderungen, Verbesserungen und vor allem die Info, ob der Spass klappt sind gern gesehen. (ich weiss, codetechnisch keine grandiose Leistung)

Edit: Natürlich werden überzählige User nicht gelöscht, das bitte händisch in den entsprechenden Files machen und "modsave all" aufrufen.

[cuma]

Ganz simpel, und doch wirksam. Noch anmerkungen dazu:
-wäre es nicht besser, die AVM Datei mit Parameter "$*" aufzurufen um einfach alles durchzureichen statt "-v -m $@"?
-ist es vielleicht nich besser, die original Datei in ein Verzeichnis ausserhalb von PATH zu verschieben. Dann hat der Prozess nachher den gleichen Namen. So würden Signale und killall noch funktionieren.
-beim grep noch ein "^" vor root und ftpuser
Aber sonst nichts :-]

[cinereous]

Die Parameter "-v -m $@" sind derweil noch beabsichtigt. -v ist Verbose, -m das Logging in einer Datei (kann natürlich beides weggelassen werden, ich wollte nur die Ausgaben), $@ und $* … Da war meine Überlegung groß. Kennst du den genauen Unterschied? Denn eigentlich ist nur einer erkennbar, und der hat was mit dem Quoting der einzelnen Parameter zu tun, sollte es passieren. Und da ist $@ die imho bessere Wahl. Pathänderung: Tu dir keinen Zwang an.

Wieso änderst du nicht den Patch einfach und hängst ihn hier an? Zeitlich hänge ich grad so tief in der Migration einer kompletten Firma auf neue Soft- und Hardware, dass ich echt nur rotiere (Und ich hasse SAP).

[cuma]

Hallo, wollte zuerst mal hören, was dzu geschreiben wird. Hab jetzt den Pfad /usr/bin/avm/ angelegt für die Binary. Vielleicht kommen da ja noch welche dazu… Grep habe ich noch ein ":" angehängt

---

cat x
#!/bin/sh
echo Parameterzahl: $#
echo x: $@
echo y: $*

./x "1 2" 3
Parameterzahl: 2
x: 1 2 3
y: 1 2 3

---

Beide sind so nicht korrekt! Klappt solange keine Anfürungszeichen gebaucht werden, sollte also eigentlich hier kein Problem sein. Hab aber gerad aber keine andere Lösng dafür.

PS: Viel Spass mit SAP :-p

[cinereous]

Implemented in r1952.

Nicht perfekt, nicht die allerbeste als Lösung, aber immerhin funktioniert das so einigermassen. Danke an cuma für kleine Verbesserungen.

[McNetic]

—— cat x
#!/bin/sh
echo Parameterzahl: $#
echo x: $@
echo y: $*

./x "1 2" 3
Parameterzahl: 2
x: 1 2 3
y: 1 2 3 ——
cBeide sind so nicht korrekt! Klappt solange keine Anfürungszeichen gebaucht werden, sollte also eigentlich hier kein Problem sein. Hab aber gerad aber keine andere Lösng dafür.

Naja. Mit den echos kannst Du nicht sehen, ob das korrekt ist. Vgl. 'echo 1 2 3' vs. 'echo "1 2" 3'.

Korrekt ist aber beides trotzdem nicht, sollte es allerdings sein mit "$@". Das erklärt sich auch aus der Bash-Manpage (die sich hier wohl konform zur sh verhält). Man sieht es so:

---

b()
{
echo $#
}

a()
{
b $*
b "$*"
b $@
b "$@"
}

a 1 2 3
a "1 2" 3

---

[cuma]

Ja, es muss wohl "$@" heissen. Ich habs mal wieder geöffnet, damit es nicht untergeht. Bitte einchecken!

[kriegaex]

Zwei Anmerkungen:

1.) Man braucht sich nicht unbedingt auf Vermutungen zum Verhalten von Ash vs. Bash zu verlassen, wenn man das Paket "ash" unter Debian (woanders heißt es evtl. anders) installiert. Es verweist dann wohl auf "dash", das mit installiert wird, und sorgt gleich noch dafür, daß die /bin/dash auch unter dem Synonym /bin/ash verfügbar gemacht wird. Eine passende Manpage hat man auch gleich, und man ash sagt dann:

Special Parameters
...
    *    Expands to the positional parameters, starting from one.
         When the expansion occurs within a double-quoted string
         it expands to a single field with the value of each parameter
         separated by the first character of the IFS variable, or by a
         <space> if IFS is unset.
    @    Expands to the positional parameters, starting from one. When
         the expansion occurs within double-quotes, each positional
         parameter expands as a separate argument. If there are no
         positional parameters, the expansion of @ generates zero
         arguments, even when @ is double-quoted. What this basically
         means, for example, is if $1 is ``abc'' and $2 is ``def ghi'',
         then "$@" expands to the two arguments:
             "abc" "def ghi"

2.) Die Wrapper-Idee ist gut. Als Alternative wäre es - evtl. auch generell in Zukunft, wenn Wrappers in solchen Fällen benötigt werden - eine Idee, mit LD_PRELOAD zu arbeiten, siehe z.B.  dort. In diesem Fall könnte ein Wrapper geschrieben werden, der in libctlusb.so die Funktion write_etc_passwd umhüllt bzw. ersetzt und das Verhalten entsprechend modifiziert. Siehe

# Check symbol table
$ toolchain/target/usr/bin/mipsel-linux-uclibc-objdump \
    -T build/original/filesystem/usr/share/ctlmgr/libctlusb.so \
      | grep -i passwd
0000311c g    DF .text  000000ec  Base        write_smbpasswd_cleartext
00003208 g    DF .text  000002cc  Base        write_etc_passwd

# Now disassemble, if you are even more curious
$ toolchain/target/usr/bin/mipsel-linux-uclibc-objdump \
    -d build/original/filesystem/usr/share/ctlmgr/libctlusb.so \
    > objdump_disassemble.txt

[cinereous]

In r2034 mit '"' eingechecked. Ich hoffe mal, das tut, was wir wollen. Denn ich kann es grad nicht testen mangels einer Umgebung, die online kommt.

[Mulder]

Inhalt von etc/passwd wird bei Aktivierung des ftp Zugriffs in der AVM Oberfläche trotz des ctlmgr Patches gelöscht. Danach sind die angelegten Nutzer weder in /etc/passwd, noch in /var/tmp/passwd vorhanden. Kurioserweise ist eine /var/tmp/passwd Datei vorhanden.

Labor-Version 54.04.99-10771-freetz-devel-2139M

[ralf]

Was ist kurios daran, daß die Datei /var/tmp/passwd vorhanden ist?

/etc/passwd befindet sich im nicht beschreibbaren Teil des Dateisystems. Damit die Datei trotzdem geändert werden kann, ist /etc/passwd ein Link auf /var/tmp/passwd. Das dateisystem in /var ist beschreibbar. Die Inhalte von beiden Dateien sollen besser gleich sein, da letztlich in beiden Fällen die gleiche Datei gelesen wird. Und /var/tmp/passwd wird auch in der original Firmware aus der Datei var.tar extrahiert.

[Mulder]

Danke für den Hinweis. Ich dachte das wäre die temporäre Datei. Hab' ich übersehen.

[oliver]

Replying to kriegaex:

2.) Die Wrapper-Idee ist gut. Als Alternative wäre es - evtl. auch generell in Zukunft, wenn Wrappers in solchen Fällen benötigt werden - eine Idee, mit LD_PRELOAD zu arbeiten, siehe z.B.  dort. In diesem Fall könnte ein Wrapper geschrieben werden, der in libctlusb.so die Funktion write_etc_passwd umhüllt bzw. ersetzt und das Verhalten entsprechend modifiziert.

Vielleicht sollten wir die Idee von Alexander versuchen. Ich hab das mal angetestet und es scheint zu funktionieren.

[cinereous]

So, da ich grad mal wieder ein wenig gucke: Was machen wir mit diesem Ticket? Der Wrapper funktioniert anscheinend, nur eben unter bestimmten Vorraussetzungen nciht. Beim Neustart des Systems wird das richtig gemacht, nur nach Änderungen auf der AVM-Oberfläche gibt es Schwierigkeiten. Somit denke ich, dass die aus ihren Sachen heraus nur ein SIGUSER oder ein HUP geben, und den Prozess somit nicht beenden. LD_PRELOAD wird dieses Problem auch nciht umgehen können, denn die Variable muss ja bei jedem Aufruf gesetzt werden, somit auch aus der AVM-Oberfläche heraus.

[kriegaex]

Replying to cinereous: Vermutungen sind gut, Kontrolle ist besser. Hast Du mit strace oder ltrace geprüft, ob Deine Vermutungen korrekt sind? Andernfalls sind sie kein sinnvoller Grund zu handeln, meine ich.

[McNetic]

Replying to cinereous:

LD_PRELOAD wird dieses Problem auch nciht umgehen können, denn die Variable muss ja bei jedem Aufruf gesetzt werden, somit auch aus der AVM-Oberfläche heraus.

Man müsste eben entweder LD_PRELOAD global setzen (was aber zu einem unnötigen Öffnen der Bibliothek bei jedem Programmaufruf führen könnte - je nach dem, wie intelligent der Kernel/die libc das handhabt, was ich nicht weiss), oder eben einen entsprechenden Wrapper für jedes Binary von AVM bauen, das die Library verwendet (was ja nicht schwer herauszufinden ist).

[cinereous]

Da dieser Wrapper unter "Normalbedingungen" tut, was er soll, und nur bei Änderungen aus dme AVM-Webinterface macht, schiebe ich die LD_PRELOAD-Geschichte auf Freetz-1.1

Ich favorisiere die Preload-Geschichte, da sie eindeutig sauberer ist, und werde da auch noch Zeit investieren wollen, nur wie gesagt: Es tut ja in den meistne Fällen erstmal, was es soll.

[oliver]

Ich hänge mal meinen Vorschlag an. Ich wäre dafür, dass wir eine Kombatilitäts-Bibliothek machen und diese mit einem globalen LD_PRELOAD immer mit laden.

[darkyputz]

So…ich habe mir nun auch mal die beiden scripte im freetz verewigt und muss auf den ersten blick feststellen, das avm mir meine passwd nicht mehr im stundentakt zurücksetzt. Von diesem standpunkt aus funktioniert er schonmal hervorragend. Nun muss ich mir noch draufschaffen wie ich via adduser meine user persistent in der box verewige. aber ich würde das agnze schonmal als erfolg bezeichnen wollen…

[Darkyputz]

Oki…neuer stand…trunk 2537 mit libfreetz patch und das usermanagment rennt so wie ich es brauche… einfach user in die /etc/passwd bzw /tmp/passwd eintragen, ein beherztes modsave flash und modsave und die user aus der passwd sind bootresistent in der fritz verewigt…

total gute arbeit…daruas liese sich ja jetzt sicher auch noch nen webif bauen werde mal versuchen was zu kidnappen

[cuma]

Ich benutz den jetzt schon seit Monaten ohne Probleme.

Um die Datei "150-rc.S-libfreetz.patch" nicht für jede Box anpassen zu müssen, könntest man das doch so machen:
sed -i 's/^export PATH runlevel prevlevel$/LD_PRELOAD="libfreetz.so.1.0.0";export PATH runlevel prevlevel LD_PRELOAD/' etc/init.d/rc.S

[matze1985]

hey leute,

ich benutzte die beiden patches jetzt auch schon seit 2 Wochen sehr erfolgreich, die Benutzer verhalten sich, wie sie sollen

Bin auch dafür, dass es ins freetz aufgenommen wird.

Matze

[astrapi]

ist der patch für die laborfirmware nicht notwendig oder nicht getestet?

[oliver]

Der Patch ist auch für die Laborfirmware nötig, aber du musst du wohl selbst Hand anlegen.

[oliver]

(In [2785]) * Add libfreetz (addresses #61)

• selected for USB_HOST boxes

[matze1985]

betrifft aus dem Changeset 2785 die  libs/Makefile.in .

Dort steht:

ifeq ($(strip $(FREETZ_LIB_libatm)),y)
LIBS+=libfreetz
endif

muss das nicht

ifeq ($(strip $(FREETZ_LIB_libfreetz)),y)
LIBS+=libfreetz
endif

heißen?

Matze

[oliver]

(In [2789]) * libfreetz: Fix typo (addresses #61)

[oliver]

Jetzt, da libfreetz im trunk ist, gibt es das nächste Problem.

Von vielen wird die Möglichkeit genutzt ein Benutzer für FTP-Zugriff auf einen USB-Datenträger anzulegen. Das Homeverzeichnis des Users gilt dann als oberste Ebene für den FTP-Zugriff. Aber sobald die modusers abgearbeitet wird wird das Verzeichnis (z.B. /var/media/ftp/uStor01/ftp) angelegt und daher der Stick unter uStor02 oder anders gemountet. Eine quick&dirty-Lösung wäre es einige Verzeichnisse auszuschließen.

cat /etc/passwd | while IFS=: read user pass uid gid gecos user_homedir shell; do
	if [ ! -d "$user_homedir" ] && echo ${user_homedir} | grep -Eqv '^/var/media/' ; then
		mkdir -p "$user_homedir"
		chown $uid:$gid "$user_homedir"
	fi
done

[ralf]

Replying to oliver:

Eine quick&dirty-Lösung wäre es einige Verzeichnisse auszuschließen.

Ich bin dafür, an dieser Stelle gar keine Verzeichnisse anzulegen, sondern für die Benutzer, die für einzelne Dienste verwendet werden, das Verzeichnis beim Start des Dienstes anzulegen.

[cuma]

Eigentlich werden bei Linux die Benutzerverzeichnisse einmal angelegt und bleiben dann. Da dies mit Freetz in home nicht möglich ist, würde ich nur Verzeichnisse die unter home liegen anlegen, dies aber beim Laden der passwd.

Auch zu bedenken ist, dass einzelne Benutzer von mehrern Daemons genutzt werden können, so vielleicht in Freetz in Zukunft der "nobody". Wenn dann jedes Skript selbst nocheinmal das Verzeichnis anlegt (vorher evtl noch löscht) und die Rechte nach eigenen Bedürfnissen setzt finde ich nicht so optimal. 

Als Rechte müsste 700 ausreichen, nicht wie momentan das Home von root mit 755.

Ich fände auch eine Verlinkung von /root noch ganz gut.

Es könnten auch /home und /root ins Flash verlagert werden, so würden der Inhalt und Rechte gespeichert und man könnte mir es sparen die .profile beim booten zu generieren

[oliver]

Ein weiteres Problem ist bei der Verwendung von libfreetz aufgetaucht: Der ctlmgr schreibt kein ftpuser Eintrag mehr in die /etc/passwd, weshalb sich der AVM ftpd nicht mehr nutzen lässt.

[oliver]

Ich hänge mal einen Patch an der verhindert, dass für die User Verzeichnisse angelegt werden. Bei der Gelegenheit hab ich gleich noch die dsmod compat section entfernt. Beim Bearbeiten der /trunk/root/usr/bin/modusers ist mir die Funktion init_passwd aufgefallen. Die könnten wir als "unsaubere" Lösung für das weiter oben geschilderte Problem nehmen. Das Homedir für den root-User wird dann in fwmod erzeugt und in var.tar gepackt. Gibts nochwas zu beachten?

[cuma]

Mit dem "modusers_no_mkdir.patch" startet openntpd nicht, da das HomeVerzeichnis nicht gefunden wird. Es sollten wohl besser alle unter /mod/home angelegt werden

[cuma]

Auch noch ein Problem durch libfreetz verursache: Es wird verhindert, dass der "ftpuser" nicht durch AVM in der /etc/passwd angelegt wird. Dessen Existenz müsste dann auch Freetz sicherstellen

[oliver]

(In [2927]) * modusers: remove compat section for old ds-mod style

• Don't create user homedirs

* Create user homedirs in rc.$pkg scripts and set permissions

All rc-scripts should keep track about their users and homedirs for themself. (refs #61)

[loomes]

Gibt es schon eine Lösung für das nichtanlegen des standard ftpuser durch libfreetz?

[cinereous]

Nein, anscheinend bisher noch nicht. Von daher schlage ich zumindest mal vor, auf den ftpuser beim Freetz-Start zu überprüfen und ihn notfalls anzulegen, falls er nicht existent ist. So ist das AVM-Standardzeugs wiederhergestellt, und zumindest dieses Problem umgangen. Auch wenn es keine wirkliche Lösung ist Würde AVM ne API für ihren Kram veröffetnlichen, dann könnte man das auch innerhalb der libfreetz-berücksichtigen, aber so…

[cuma]

Das ist wohl die einfachste Lösung. Hatte ich vor 6 Wochen schon angeregt. Die ganzen Pakete prüfen ja auch ihre User und legen sie an

[oliver]

Ich hänge mal eine Idee an, wie der Patch aussehen könnte.

Nachteil: Das Passwort wird bei jedem Neustart der Box auf das in der ar7.cfg festgelegte Passwort gesetzt. Zur sofortigen Änderung müsste man in der libfreetz die Änderung abfangen und selbst durchführen.

Leider gibt es da aktuell ein Problem mit den Laborversion, da hier von AVM eine /var/flash/usb.cfg eingeführt wurde. Damit funktioniert diese Idee also schon nicht mehr.

[cuma]

Wäre es nicht besser diese existierende Funktion in libfreetz zu erweitern:

write_etc_passwd ()
{
  return;
}

Und zwar so, dass bei jedem Aufruf die Passwortdatei mit dem aktuellen Passwort geupdated wird, bzw ftpuser angelegt wird wenn er nicht existiert. Das hätte den Vorteil dass es beim Systemstart der ftpuser da ist und beim Passwortändern auch gleich das neue eingetragen wird. Dafür sehe ich 2 Möglichkeiten: -Einfach ein "exec" in die Funktion welches ein Skript (modusers-Patch aus dem letzten Post?) aufruft -Das ganze gleich in C in die Library.

[oliver]

Mein kürzlich angehängter Patch funktioniert nicht so wie gedacht, daher verschiebe ich diese Problem nach 1.2.

[oliver]

Jetzt da wir von Hermann eine rc.ftpd haben könnten wir den ftpuser schonmal darin anlegen. Fragt sich jetzt nur noch was wir mit dem Passwort machen. Das in C zu implementieren dürft schwierig werden, weil wir zur Entschlüsselung des Passworts aus der ar7.cfg die AVM-Funktionen kennen müssten. Wenn wir dann Skripte aufrufen, dann können wir es auch gleich als Skript machen. Problematisch hierbei ist noch, dass der AVM ftpd keine Passwörter aus der /etc/shadow lesen kann. Ich hab mich schon versucht den ftpd selbst zu bauen bin mit den AVM Sourcen aber nicht weit gekommen…

[Mulder]

libfreetz_0.2_update.patch funktioniert im Prinzip. Statt boxusr80 habe ich wieder den ftpuser in der passwd Datei. Die Funktion "Kennwortschutz aktivieren" hat keinen Einfluß mehr auf das Passwort von boxusr80 oder ftpuser in der passwd Datei. Beide passwörter müssen mit passwd manuell gesetzt werden. Den boxusr80 Account habe ich ebenfalls manuell angelegt.

Normalerweise wird bei Verwendung von "Kennwortschutz aktivieren" ein Kennwort in den Account boxusr80 eingetragen. Warum der account ftpuser mit libfreetz_0.1 nicht da war, weiß ich nicht. Allerdings funktionierten ohne diesem auch einige Zugriffe auf ftp Ressourcen, welche man aus der Weboberfläche heraus machen kann nicht.

Getested mit gefreezter FRITZ.Box_Fon_WLAN_7270_v3_Labor_74.04.80-16376

[oliver]

#699 closed as duplicate

[henfri]

Hallo,

ist der Patch im Trunk enthalten? Ich habe das Problem, dass Samba mein Passwort nicht mehr akzeptiert seit dem update auf die 7270_labor_nas_04.80freetz-devel-4430. Vorher hatte ich die 7270_labor_beta_04.78freetz-devel-3962. Damit hatte ich keine Probleme.

Gruß, Hendrik

[henfri]

P.S: über ftp kann ich mich als ftpuser anmelden. Nur über Samba habe ich dieses Problem

[oliver]

Nein, ist noch nicht drin.

[oliver]

(In [4436]) * libfreetz: Fix for newer labor firmwares

• AVM changed name of the function we overload
• refs #61