[Problem] vsftpd funktioniert nicht mehr - mehr Verbose

[CaptainMorgan]

Hallo.
Ich hatte das ganze letzte Jahr einen vsftpd Server eingerichtet, auf 6.83 plus Freetz.
Das ganze auch mit TLS.

Dann ist mir zum Jahresende die Box komplett abgeschmirt, was ich zum Anlass genommen habe alles auf 7.01 zu updaten und neu aufzusetzen.
Seit Neujahr sitze ich jetzt daran auf 7.01-15014 wieder vsftpd ans laufen zu kriegen, sowohl auf einer 7362SL als auch einer 7560.

Das Problem an meinem Problem, leider wirft vsftpd so gut wie nichts aus. Mir ist bewusst wie wenig Hebel zur Problemläsung ich hier im ersten Post nur anbiete, deswegen wäre meine erste Frage ob es vielleicht noch eine erweiterte Log gibt?

Anderenfalls, falls jemandem das folgende bekannt vorkommt, hier mein vorgehen und das schiefgehen.
-alle selbsterstellten benutzer aus /cat/passwd gelöscht
-neues Image eingespielt: vsftpd (mit SSL, sowohl static als auch nicht static schon probiert), OPENSSL, OpenVPN (auch problematisch siehe anderer Thread, aber nur auf der 7560) und samba (funktioniert weiter gut)
-vsftp mit Standardeinstellungen + port 2121: ein anonymer Login funktioniert, natürlich kein Homeverzeichnis
-vsftp anhalten, adduser -h /var/media/ftp/ TEST, pass 123
-modsave all
-auf lokale Benutzer und chroot umstellen, config_dir angeben mit einer Datei, TEST [write_enable=yes]
-log in seperate Datei, beide Menüpunkte aktiviert
-vsftpd wieder an
Fillezilla

Status: Verbinde mit 192.168.172.2:2121...
Status: Verbindung hergestellt, warte auf Willkommensnachricht...
Status: Unsicherer Server; er unterstützt kein FTP über TLS.
Befehl: USER TEST
Antwort: 331 Please specify the password.
Befehl: PASS ********
Antwort: 500 OOPS: munmap
Fehler: Kritischer Fehler: Herstellen der Verbindung zum Server fehlgeschlagen

vsftpdlog stellt sich auch vollkommen doof:

Fri Jan 11 16:12:00 2019 [pid 2836] CONNECT: Client "192.168.172.58"
Fri Jan 11 16:12:00 2019 [pid 2836] FTP response: Client "192.168.172.58", "220 (vsFTPd 3.0.3)"
Fri Jan 11 16:12:00 2019 [pid 2836] FTP command: Client "192.168.172.58", "AUTH TLS"
Fri Jan 11 16:12:00 2019 [pid 2836] FTP response: Client "192.168.172.58", "530 Please login with USER and PASS."
Fri Jan 11 16:12:00 2019 [pid 2836] FTP command: Client "192.168.172.58", "AUTH SSL"
Fri Jan 11 16:12:00 2019 [pid 2836] FTP response: Client "192.168.172.58", "530 Please login with USER and PASS."
Fri Jan 11 16:12:00 2019 [pid 2836] FTP command: Client "192.168.172.58", "USER TEST"
Fri Jan 11 16:12:00 2019 [pid 2836] [TEST] FTP response: Client "192.168.172.58", "331 Please specify the password."
Fri Jan 11 16:12:00 2019 [pid 2836] [TEST] FTP command: Client "192.168.172.58", "PASS <password>"
Fri Jan 11 16:12:00 2019 [pid 2833] [TEST] OK LOGIN: Client "192.168.172.58"

Man beachte das die Log von AUTH TLS faselt, obwohl diesbezüglich noch alles deaktiviert ist.
Wenn ich es aktiviere und Certifikat und Key einsetze:
Filezilla:

Status: Verbinde mit 192.168.172.2:2121...
Status: Verbindung hergestellt, warte auf Willkommensnachricht...
Antwort: 220 (vsFTPd 3.0.3)
Befehl: AUTH TLS
Antwort: 234 Proceed with negotiation.
Status: Initialisiere TLS...
Status: Überprüfe Zertifikat...
Status: TLS-Verbindung hergestellt.
Befehl: USER TEST
Antwort: 331 Please specify the password.
Befehl: PASS ******
Fehler: GnuTLS-Fehler -15: An unexpected TLS packet was received.
Fehler: Herstellen der Verbindung zum Server fehlgeschlagen
Status: Nächsten Versuch abwarten...
Status: Verbinde mit 192.168.172.2:2121...
Status: Verbindung hergestellt, warte auf Willkommensnachricht...
Antwort: 220 (vsFTPd 3.0.3)
Befehl: AUTH TLS
Antwort: 234 Proceed with negotiation.
Status: Initialisiere TLS...
Status: Überprüfe Zertifikat...
Status: TLS-Verbindung hergestellt.
Befehl: USER TEST
Antwort: 331 Please specify the password.
Befehl: PASS ******
Fehler: GnuTLS-Fehler -15: An unexpected TLS packet was received.
Fehler: Herstellen der Verbindung zum Server fehlgeschlagen

Und vsftpd.log:

Fri Jan 11 16:14:32 2019 [pid 5293] CONNECT: Client "192.168.172.58"
Fri Jan 11 16:14:32 2019 [pid 5293] FTP response: Client "192.168.172.58", "220 (vsFTPd 3.0.3)"
Fri Jan 11 16:14:32 2019 [pid 5293] FTP command: Client "192.168.172.58", "AUTH TLS"
Fri Jan 11 16:14:32 2019 [pid 5293] FTP response: Client "192.168.172.58", "234 Proceed with negotiation."
Fri Jan 11 16:14:32 2019 [pid 5293] FTP command: Client "192.168.172.58", "USER TEST"
Fri Jan 11 16:14:32 2019 [pid 5293] [TEST] FTP response: Client "192.168.172.58", "331 Please specify the password."
Fri Jan 11 16:14:32 2019 [pid 5293] [TEST] FTP command: Client "192.168.172.58", "PASS <password>"
Fri Jan 11 16:14:32 2019 [pid 5292] [TEST] OK LOGIN: Client "192.168.172.58"
Fri Jan 11 16:14:37 2019 [pid 5306] CONNECT: Client "192.168.172.58"
Fri Jan 11 16:14:37 2019 [pid 5306] FTP response: Client "192.168.172.58", "220 (vsFTPd 3.0.3)"
Fri Jan 11 16:14:37 2019 [pid 5306] FTP command: Client "192.168.172.58", "AUTH TLS"
Fri Jan 11 16:14:37 2019 [pid 5306] FTP response: Client "192.168.172.58", "234 Proceed with negotiation."
Fri Jan 11 16:14:37 2019 [pid 5306] FTP command: Client "192.168.172.58", "USER TEST"
Fri Jan 11 16:14:37 2019 [pid 5306] [TEST] FTP response: Client "192.168.172.58", "331 Please specify the password."
Fri Jan 11 16:14:37 2019 [pid 5306] [TEST] FTP command: Client "192.168.172.58", "PASS <password>"
Fri Jan 11 16:14:37 2019 [pid 5305] [TEST] OK LOGIN: Client "192.168.172.58"

Dieses Verhalten habe ich sowohl auf der 7362SL und auf der 7560, mit zwei Filezilla auf zwei unterschiedlichen Windows Maschinen, aber auch diverse Android Tie-Inns funktionieren nicht mehr, halt nur mit noch weniger Rückmeldungen.

Ich bin jetzt seid fast vier Wochen Abends daran am tüfteln, seid Neujahr auch die Nächte.
Ich weiß dass das nicht viel ist, aber entweder bin ich der einzige der vsftpd noch benutzt, und es gibt einen Fehler im Code an dem sich sonst keiner mehr stört, oder aber ich mache einen systematischen Fehler, den ich aber auf Teufel komm raus nicht finde.

Vielleicht hat ja jemand Input für mich....

 

[Shirocco88]

Status: Verbinde mit 192.168.172.2:2121...
Status: Verbindung hergestellt, warte auf Willkommensnachricht...
Status: Unsicherer Server; er unterstützt kein FTP über TLS.
Befehl: USER TEST
Antwort: 331 Please specify the password.
Befehl: PASS ********
Antwort: 500 OOPS: munmap
Fehler: Kritischer Fehler: Herstellen der Verbindung zum Server fehlgeschlagen

das sieht nach "Error: 500 OOPS: vsftpd: refusing to run with writable root inside chroot()" aus;
Lösungsvorschlag: Option allow_writeable_chroot=YES setzen.

Ergänzend: Könntest Du Bitte den Befehlsoutput "ps | grep vsftpd" posten.

 

[CaptainMorgan]

Lösungsvorschlag: Option allow_writeable_chroot=YES setzen

In der config "TEST" im Benutzerordner oder der allgemeinen vsftpd.config ?

Edit: Beides getestet, scheint keinen Unterschied zu machen.

Ergänzend: Könntest Du Bitte den Befehlsoutput "ps | grep vsftpd" posten.

30630 root      2900 S    vsftpd
30854 root      1312 S    {busybox} grep vsftpd

 

[Shirocco88]

Bitte mal das vsftpd config file posten:

cat /mod/etc/vsftpd.conf

adduser -h /var/media/ftp/ TEST, pass 123

Warum verwendest Du einen Usernamen mit Großbuchstaben ?
eigentlich sind die Usernamen immer kleingeschrieben.

 

[CaptainMorgan]

background=yes
check_shell=no
listen=yes
anonymous_enable=no
local_enable=yes
local_umask=022
chroot_local_user=yes
passwd_chroot_enable=yes
write_enable=yes
nopriv_user=root
secure_chroot_dir=/var/run/vsftpd
listen_port=2121
userlist_enable=yes
anon_root=/mod/home/ftp
xferlog_std_format=no
xferlog_enable=yes
vsftpd_log_file=/var/media/ftp/uStor01/logs/vsftpd.log
log_ftp_protocol=yes
syslog_enable=no
max_clients=25
max_per_ip=5
pasv_min_port=0
pasv_max_port=0
pasv_promiscuous=no
delay_failed_login=15
chroot_list_enable=yes
ssl_enable=yes
ssl_sslv2=no
ssl_sslv3=no
ssl_tlsv1=yes
force_local_data_ssl=yes
force_local_logins_ssl=yes
user_config_dir=/var/media/ftp/uStor01/vsftp_user_conf
allow_writeable_chroot=yes

Edit: Werde den Usernamen mal klein machen, war unbewusst, sollte ja aber doch theoretisch keinen Unterschied machen?

 

[stoney]

Linux ist recht zimperlich wenn es um Groß- und Kleinschreibung geht - anders als Windows

 

[CaptainMorgan]

Da scheint einfach irgendwas nicht rundzulaufen. Habe jetzt User "test" und pass "123".
Zunächst kamm wieder 500:OOPS munmaps.
Dann habe ich ein paar falsche Passwörter eingegeben, was auch 530: Login Incorrect geworfen hat, was ja stimmt.
Dann habe ich wieder das richtige verwendet, jetzt kann ich navigieren, sobald ich eine Datei hoch oder runter laden will kommt wieder 500:OOPS munmap.
Neue Session: Wieder munmaps beim Login. Beim 5ten mal geht es. Datei hochladen nein.
Solch inkonsistentes Verhalten nervt mich seit Tagen, zunächst sah es so aus als hätte es etwas mit Leerzeichen im Benutzernamen zu tun, deswegen hatte ich ja bereits einen alten Thread ausgegraben, aber das ist es offensichtlich nicht gewesen.
Manchmal funktioniert auch der erste Test bei einem neuen Benutzer. Oder nach Einspielen eines neuen Images. Aber ein echter Transfer funktioniert nie.

 

[Shirocco88]

das sieht nach "kaputtem SSL-/TLS-Support" bei vsftpd Binary aus;

Hast Du schon die /mod/etc/vsftpd.conf mit deaktiviertem ssl-/tls-Support getestet ?

ssl_enable=no
ssl_sslv2=no
ssl_sslv3=no
ssl_tlsv1=no
force_local_data_ssl=no
force_local_logins_ssl=no

In der config "TEST" im Benutzerordner

wie sieht den die per user vsftpd config Ergänzung aus ?

Ist es möglich, das vsftpd Binary ohne SSL-/TLS-Support mal zu erstellen und zu testen; idealerweise als static-Binary mit external option, dann kann man den vsftpd auf USB-Stick ablegen und von dort aus starten und testen.

Bitte auch .config Datei beifügen, dann sieht man mehr.

 

[CaptainMorgan]

Config's vom letzten Image im Anhang.

das sieht nach "kaputtem SSL-/TLS-Support" bei vsftpd Binary aus;

Hast Du schon die /mod/etc/vsftpd.conf mit deaktiviertem ssl-/tls-Support getestet ?

Ja, auch mit Standardeinstellungen, und nichts als einem "test"-Benutzer gibt es dieses Verhalten.

wie sieht den die per user vsftpd config Ergänzung aus ?

write_enable=yes
allow_writeable_chroot=yes

Ist es möglich, das vsftpd Binary ohne SSL-/TLS-Support mal zu erstellen und zu testen; idealerweise als static-Binary mit external option, dann kann man den vsftpd auf USB-Stick ablegen und von dort aus starten und testen.

Mache ich so bald wie möglich.
Zwei Fragen dazu:
-Hat das eigenständige OpenSSL-Package darauf einen Einfluss?
-Ohne SSL Support und static ist mir klar, aber wie bewerkstellige ich die external option?

 

[Shirocco88]

aber wie bewerkstellige ich die external option?

im 'make menuconfig' die entsprechende Option enablen

cat .config
SNIP
#
# External processing
#
# EXTERNAL_ENABLED is not set

und dann kann man viele Packages "externalisieren", d.h. vom Root-FS in ein anderes Filesystem, z.B. "/var/media/ftp/<USB-Stick>" auslagern.

make/vsftpd/external.files:[ "$EXTERNAL_FREETZ_PACKAGE_VSFTPD" == "y" ] && EXTERNAL_FILES+=" /usr/sbin/vsftpd"
make/vsftpd/external.in:config EXTERNAL_FREETZ_PACKAGE_VSFTPD
make/vsftpd/external.in:        depends on EXTERNAL_ENABLED && FREETZ_PACKAGE_VSFTPD
make/vsftpd/external.in:                externals the following file(s):
make/vsftpd/external.services:[ "$EXTERNAL_FREETZ_PACKAGE_VSFTPD" == "y" ] && EXTERNAL_SERVICES+=" vsftpd"

 

[CaptainMorgan]

Ah external processing.
Ja, ich habe jetzt eine ca. 283kb große EXTERNAL Datei. Die lege ich einfach vorm Enspielen in uStor01 ab?

 

[Shirocco88]

Ja, ich habe jetzt eine ca. 283kb große EXTERNAL Datei.

nimm doch Subdirectory, statt Container-Datei;

https://freetz.github.io/wiki/help/howtos/common/external.html

Ich hatte das ganze letzte Jahr einen vsftpd Server eingerichtet, auf 6.83 plus Freetz.
Das ganze auch mit TLS.

d.h. wenn Du den Freetz-Trunk mit dem entsprechenden Changeset aus dem Github auscheckst, das 6.83 Image in den Download-Ordner legst und das vsftpd Binary mit static und external option compilierst, sollte dies auch in FW 07.01 mit selbst erstellter Configdatei /mod/etc/vsftpd.conf laufen.

 

[CaptainMorgan]

d.h. wenn Du den Freetz-Trunk mit dem entsprechenden Changeset aus dem Github auscheckst, das 6.83 Image in den Download-Ordner legst und das vsftpd Binary mit static und external option compilierst, sollte dies auch in FW 07.01 mit selbst erstellter Configdatei /mod/etc/vsftpd.conf laufen.

An das genaue Changeset erinnere ich mich leider nicht mehr, aber wenn ich eh nur die vsftpd ändern würde, das muss man doch auch einfacher schauen können ob sich an den binaries im letzten halben Jahr was geändert hat?
Edit:
Ich habe das mit der dem External File probiert, seitdem hängt die Box im "verlängerten" Boot-Loop...
Edit2:
So, bin nun wieder da wo ich vor 6 Stunden war. Netter Abend....
Probiere jetzt mit subdirectories

 

[stulle]

Ich hänge mich mal hier rein, da ich gefühlt schon lange das gleiche Problem habe, auf mehreren Rechnern bzw. Clients. Meistens kommt ein "..OOPS: munmap" mehrmals hintereinander klicken und dann geht es, oder wenn ich im Ordner eine oder mehrere Dateien bearbeiten oder löschen will kommt de Meldung, dass der Server die Daten nicht akzeptiert. Es kommt auch vor, dass bei einem Neustart der Box der vsftpd gar nicht gestartet ist oder der Restartbutton mehrmals gedrückt werden muss.
Ich benutze vsftp schon mehrere Jahre, immer ohne ssl kompiliert, bei meiner früheren 7390 (vsftp extern ausgelagert im internen Speicher der Box) kannte ich diese Probleme nicht. Jetzt benutze ich eine 7590 und hier waren diese Probleme von Anfang an, egal ob stable und jetzt labor.
Die Logdatei ist auch nicht besonders redselig. Habe nun auch schon einiges durchprobiert und werde nicht schlauer. Für mich ist das Problem erst mal nicht so schwerwiegend, da meine Kameras ohne weitere Probleme ihre Bilder und Videos auf dem Server ablegen.
Meine configs sehen so etwa aus wie von #captain..

edit:
die vsftpd bin 3.03 release hat sich seit Jahren nicht mehr geändert, ich denke hier liegt ein Problem der Anpassung mit dem neueren Kernel der FritzBox vor

 

[CaptainMorgan]

@stulle:
Dann kennst du ja die Frustration. Bekommst du denn eine stabile ausgelagerte Variante mit 7.01-15014 hin?


Ich habe vorhin irgendwas falsch gemacht. Was auch immer das external File auf meinem USB-Stick installiert hat, selbst bei der zurückgesetzten Box, hat bewirkt dass innerhalb von zwei Minuten der komplette Speicher vollgelaufen ist.
Wenn einer von euch mir eine Schritt für Schritt Anleitung geben kann wie das mit dem "external processing" funktionieren soll wage ich noch einen Versuch.

Edit: Habe jetzt ein Image (configs im Anhang) und einen ordner external. Darin "/usr/sbin/vsftp" sowie ".external", "external.pkg".
Das wiki empfiehlt ausschließlich das Hochladen einer Datei, nicht das einfügen der subdirectories, deswegen wäre ich von hier an über Hilfe froh wie das unfallfrei geht.

 

[stulle]

Ich kann dir da im Moment auch nicht helfen. Ich sehe da aber jetzt keinen Zusammenhang mit deinem bzw. auch meinem Problem. Ich habe es immer so verstanden, das ein Auslagern Sinn macht, wenn der Ram-Speicher der Box nicht reicht. Es ist jetzt schon länger her, müsste mich auch wieder einlesen, ich habe damals auf der 7390 außer vsftpd auch noch samba wegen Speichermangel ausgelagert. Der Pfad musste angeben weden. bei mir war der intern /var/media/ftp, ich brauchte keinen USB-Stick, hängt also von der benutzten Box ab. Ich glaube nicht, dass ein auslagern das Problem löst.

 

[CaptainMorgan]

@stulle Deine 7590 hat doch bestimmt auch ein 7ner OS?
Vielleicht hat es damit zu tun.
@Shirocco88Sollte ich ein ausgelagertes vsftpd ans laufen bekommen, würde ich dann nur einen weiteren Versuch machen, oder kann man so mehr testen?
Edit: Backblaze sei Dank, habe ich noch 3 alte Images gefunden.
Ich werde da morgen mal reinschauen.

 

[Shirocco88]

die Motivation des Externalisierens ist in diesem Fall nicht ein Speichermangel (z.B. im Root-FS) zu vermeiden, sondern wie in #12 beschrieben, ein funktionierendes static Binary (aus dem genannten Setup #1, d.h. 6.83 mit Freetz CS xxxxx) in der vorhanden Freetzbox mit 7.01 zu testen; sollte das funktionieren, dann hat man einen Workaround;
wenn das Binary gleiche Probleme zeigt, dann kann es eigentlich nur an Änderungen bei Freetz bzw. an AVM FW-Änderungen (Kernel, ...) liegen und man muß ggf. weiter analysieren.
Andere Methoden (strace, ...) haben IMHO hohe Komplexität, daher der Vorschlag des Ausschlußverfahrens (Crosstausch mit funktionierendem Binary).

 

[PeterPawn]

Wer möchte, kann ja mal den folgenden Patch vor dem Build für "vsftpd" in das Verzeichnis "make/vsftpd/patches" legen (z.B. als "900-ignore_munmap_error.patch"):

--- sysutil.c
+++ sysutil.c
@@ -1152,6 +1152,12 @@
   }
 }

+void
+vsf_sysutil_memunmap_noerror(void* p_start, unsigned int length)
+{
+  int retval = munmap(p_start, length);
+}
+
 static int
 vsf_sysutil_translate_openmode(const enum EVSFSysUtilOpenMode mode)
 {
--- secbuf.c
+++ secbuf.c
@@ -14,6 +14,9 @@
 #include "sysutil.h"
 #include "sysdeputil.h"

+void vsf_secbuf_free_noerror(char**);
+void vsf_sysutil_memunmap_noerror(void*, unsigned int);
+
 void
 vsf_secbuf_alloc(char** p_ptr, unsigned int size)
 {
@@ -24,7 +27,7 @@
   unsigned int page_size = vsf_sysutil_getpagesize();

   /* Free any previous buffer */
-  vsf_secbuf_free(p_ptr);
+  vsf_secbuf_free_noerror(p_ptr);
   /* Round up to next page size */
   page_offset = size % page_size;
   if (page_offset)
@@ -87,3 +90,29 @@
   vsf_sysutil_memunmap(p_mmap, map_size);
 }

+void
+vsf_secbuf_free_noerror(char** p_ptr)
+{
+  if (*p_ptr == 0)
+  {
+    return;
+  }
+  unsigned int map_size;
+  unsigned long page_offset;
+  char* p_mmap = *p_ptr;
+  unsigned int page_size = vsf_sysutil_getpagesize();
+  /* Calculate the actual start of the mmap region */
+  page_offset = (unsigned long) p_mmap % page_size;
+  if (page_offset)
+  {
+    p_mmap -= page_offset;
+  }
+  p_mmap -= page_size;
+  /* First make the first page readable so we can get the size */
+  vsf_sysutil_memprotect(p_mmap, page_size, kVSFSysUtilMapProtReadOnly);
+  /* Extract the mapping size */
+  map_size = *((unsigned int*)p_mmap);
+  /* Lose the mapping */
+  vsf_sysutil_memunmap_noerror(p_mmap, map_size);
+}
+

Was macht der?

Innerhalb des "vsftpd" gibt es die Implementierung eines "secure buffer" - jeder Zugriff außerhalb der Seitengrenzen dieses Buffers wird mit SIGSEGV geahndet.

Wird ein solcher Buffer angefordert und die Variable, in der seine Adresse gespeichert werden soll, ist nicht NULL (das ist der Wert für einen unbenutzten, aber initialisierten Pointer), wird zuerst versucht, zuvor an dieser Adresse gemappten Speicher freizugeben - das ist dann so ein "munmap"-Aufruf.

Bei einem gültigen Pointer gibt es keinen nachvollziehbaren Grund, warum ein "munmap" (mit korrekter Länge) jemals fehlschlagen sollte ... hier wird aber mit allerlei Kunststückchen versucht, eine Art "Selbstverwaltung" zu organisieren, indem vor und nach dem eigentlichen Buffer jeweils eine Seite per MMU auf "kein Zugriff" gesetzt wird, so daß ein Überschreiten der Buffergrenzen (zumindest dann, wenn der an einer "page boundary" beginnt) zum gewünschten Abbruch führt. Dazu wird in der ersten Seite (die vor dem Buffer liegt) die Länge des gesamten gemappten Speichers abgelegt und vor dem Freigeben wieder eingelesen.

Nun funktioniert das natürlich nur dann, wenn der "alte Wert" im Pointer auch tatsächlich auf einen solchermaßen erzeugten Buffer zeigt ... ist das nicht der Fall, wird nur sehr selten dort die korrekte Länge stehen und eine falsche Längenangabe ist z.B. ein plausibler Grund, warum ein "munmap" schiefgehen kann.

Wenn also irgendwo im Rest des Codes von "vsftpd" ein Pointer nicht korrekt initialisiert wird (das kann auch bei Unterschieden in der Plattform schon mal passieren - nicht jede Plattform initialisiert alle Datenbereiche automatisch mit binären Nullen) und dieser dann für ein "vsf_secbuf_alloc()" benutzt wird, dann kann es beim Versuch der Freigabe eines gar nicht gemappten Speicherbereichs zu diesem Problem kommen. Die eigentliche Ursache liegt zwar immer noch im nicht korrekt initialisierten Pointer (wenn meine Annahme stimmt), aber diesem Problem ist ziemlich schlecht hinterherzulaufen.

Als Workaround (und das macht der Patch) kann man auch den Abbruch bei einem Fehler im "munmap" einfach übergehen, wenn es sich beim "vsf_secbuf_free()"-Aufruf um einen handelt, der implizit erfolgt, bevor der Pointer mit einem neuen Wert überschrieben wird. Als schnelle Lösung (die man ggf. auch noch mit zusätzlicher Protokollierung anreichern kann, wenn man dann erst einmal festgestellt hat, daß/ob sie wirksam ist) werden einfach doppelte Funktionen verwendet, bei denen am Ende der "munmap"-Fehler ignoriert wird - die Alternative wäre eine Erweiterung der Funktionen um einen Parameter, ob der Prozess nun sterben sollte oder nicht.

Was riskiert man mit diesem Patch? Sollte sich hinter dem Pointer tatsächlich ein ordnungsgemäß gemappter Speicherbereich verbergen, der bei der Freigabe einen Fehler liefert (dessen Ursache wäre dann erst mal zu (er-)klären), wird der eben nicht freigegeben ... der neue Bereich wird aber trotzdem bereitgestellt. Auf Dauer könnte sich so also ein Speicherleck ergeben, wenn immer wieder Bereiche nicht freigegeben werden. Die Sicherheit des Servers wird durch den Patch aber nicht beeinflußt - jedenfalls kann ich das nicht erkennen (wenn man mal von sehr exotischen Problemen wie Pointerüberlauf durch falsche Längenangaben in der "pre-page" absieht) - höchstens eben durch den "Verbrauch" des gesamten verfügbaren Speichers..

Wenn der Patch gegen das "500 OOPS: munmap" helfen sollte (das kommt m.E. beim Einrichten einer neuen Session, wenn der Buffer für die "Kommandozeile" zugeordnet werden soll), kann man ihn weiter ausbauen und mit der Ausgabe von zusätzlichen Debug-Informationen versuchen, dem eigentlichen Problem auf den Grund zu gehen. Wenn er nicht hilft ... auch gut - dann weiß man aber wenigstens, daß es nicht an dieser "impliziten Freigabe" eines älteren Buffers liegt, dessen Adresse im Pointer gespeichert ist.

Je nachdem, wie man den "vsftpd" am Ende startet (als Standalone-Daemon oder über den "inetd"), verschwinden die Mappings aber ohnehin wieder beim Ende des Prozesses ... wenn man hier also einen permanent wachsenden Speicherbedarf erkennen will, darf man den "vsftpd" nicht "on demand" starten lassen.

 

[CaptainMorgan]

Wer möchte, kann ja mal den folgenden Patch vor dem Build für "vsftpd" in das Verzeichnis "make/vsftpd/patches" legen (z.B. als "900-ignore_munmap_error.patch"):

Wenn ich diesen Code mit diesem Dateinamen so in diesem Ordner ablege, integriert make dann alles selbst?
Edit: Habe ich in der Zwischenzeit probiert, das Kompilieren endet mit einem Error:

    applying patch file make/vsftpd/patches/121-no_libcap.patch
    patching file sysdeputil.c
    ----------------------------------------------------------------------
    applying patch file make/vsftpd/patches/900-ignore_munmap_error.patch
    (Stripping trailing CRs from patch; use --binary to disable.)
    patching file sysutil.c
    (Stripping trailing CRs from patch; use --binary to disable.)
    patching file secbuf.c
    patch unexpectedly ends in middle of line
    patch: **** malformed patch at line 65:

    ----------------------------------------------------------------------
ERROR: modpatch: Error in patch-file make/vsftpd/patches/900-ignore_munmap_error.patch
make/vsftpd/vsftpd.mk:25: recipe for target 'source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/.unpacked' failed
make: *** [source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/.unpacked] Error 2