.titleBar { margin-bottom: 5px!important; }

[Problem] vsftpd funktioniert nicht mehr - mehr Verbose

Dieses Thema im Forum "Freetz" wurde erstellt von CaptainMorgan, 11 Jan. 2019.

  1. CaptainMorgan

    CaptainMorgan Neuer User

    Registriert seit:
    28 Nov. 2015
    Beiträge:
    127
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    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
    vsftpdlog stellt sich auch vollkommen doof:
    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:
    Und vsftpd.log:
    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....
     
  2. Shirocco88

    Shirocco88 Aktives Mitglied

    Registriert seit:
    4 Jan. 2016
    Beiträge:
    868
    Zustimmungen:
    65
    Punkte für Erfolge:
    28
    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.
     
  3. CaptainMorgan

    CaptainMorgan Neuer User

    Registriert seit:
    28 Nov. 2015
    Beiträge:
    127
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    In der config "TEST" im Benutzerordner oder der allgemeinen vsftpd.config ?

    Edit: Beides getestet, scheint keinen Unterschied zu machen.

    Code:
    30630 root      2900 S    vsftpd
    30854 root      1312 S    {busybox} grep vsftpd
    
     
  4. Shirocco88

    Shirocco88 Aktives Mitglied

    Registriert seit:
    4 Jan. 2016
    Beiträge:
    868
    Zustimmungen:
    65
    Punkte für Erfolge:
    28
    #4 Shirocco88, 11 Jan. 2019
    Zuletzt bearbeitet: 11 Jan. 2019
    Bitte mal das vsftpd config file posten:

    Code:
    cat /mod/etc/vsftpd.conf
    Warum verwendest Du einen Usernamen mit Großbuchstaben ?
    eigentlich sind die Usernamen immer kleingeschrieben.
     
  5. CaptainMorgan

    CaptainMorgan Neuer User

    Registriert seit:
    28 Nov. 2015
    Beiträge:
    127
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    #5 CaptainMorgan, 11 Jan. 2019
    Zuletzt bearbeitet: 11 Jan. 2019
    Code:
    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?
     
  6. stoney

    stoney Moderator
    Forum-Mitarbeiter

    Registriert seit:
    7 Okt. 2015
    Beiträge:
    4,449
    Zustimmungen:
    296
    Punkte für Erfolge:
    83
    Ort:
    Bayern
    Linux ist recht zimperlich wenn es um Groß- und Kleinschreibung geht - anders als Windows
     
  7. CaptainMorgan

    CaptainMorgan Neuer User

    Registriert seit:
    28 Nov. 2015
    Beiträge:
    127
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    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.
     
  8. Shirocco88

    Shirocco88 Aktives Mitglied

    Registriert seit:
    4 Jan. 2016
    Beiträge:
    868
    Zustimmungen:
    65
    Punkte für Erfolge:
    28
    #8 Shirocco88, 12 Jan. 2019
    Zuletzt bearbeitet: 12 Jan. 2019
    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 ?
    Code:
    ssl_enable=no
    ssl_sslv2=no
    ssl_sslv3=no
    ssl_tlsv1=no
    force_local_data_ssl=no
    force_local_logins_ssl=no

    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.
     
  9. CaptainMorgan

    CaptainMorgan Neuer User

    Registriert seit:
    28 Nov. 2015
    Beiträge:
    127
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    Config's vom letzten Image im Anhang.

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

    Code:
    write_enable=yes
    allow_writeable_chroot=yes
    
    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?
     

    Anhänge:

  10. Shirocco88

    Shirocco88 Aktives Mitglied

    Registriert seit:
    4 Jan. 2016
    Beiträge:
    868
    Zustimmungen:
    65
    Punkte für Erfolge:
    28
    #10 Shirocco88, 12 Jan. 2019
    Zuletzt bearbeitet: 12 Jan. 2019
    im 'make menuconfig' die entsprechende Option enablen
    Code:
    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.

    Code:
    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"
    
     
  11. CaptainMorgan

    CaptainMorgan Neuer User

    Registriert seit:
    28 Nov. 2015
    Beiträge:
    127
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    Ah external processing.
    Ja, ich habe jetzt eine ca. 283kb große EXTERNAL Datei. Die lege ich einfach vorm Enspielen in uStor01 ab?
     
  12. Shirocco88

    Shirocco88 Aktives Mitglied

    Registriert seit:
    4 Jan. 2016
    Beiträge:
    868
    Zustimmungen:
    65
    Punkte für Erfolge:
    28
    #12 Shirocco88, 12 Jan. 2019
    Zuletzt bearbeitet: 12 Jan. 2019
    nimm doch Subdirectory, statt Container-Datei;

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

    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.
     
  13. CaptainMorgan

    CaptainMorgan Neuer User

    Registriert seit:
    28 Nov. 2015
    Beiträge:
    127
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    #13 CaptainMorgan, 12 Jan. 2019
    Zuletzt bearbeitet: 12 Jan. 2019
    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
     
  14. stulle

    stulle Neuer User

    Registriert seit:
    8 Jan. 2006
    Beiträge:
    11
    Zustimmungen:
    1
    Punkte für Erfolge:
    3
    #14 stulle, 13 Jan. 2019
    Zuletzt bearbeitet: 13 Jan. 2019
    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
     
  15. CaptainMorgan

    CaptainMorgan Neuer User

    Registriert seit:
    28 Nov. 2015
    Beiträge:
    127
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    #15 CaptainMorgan, 13 Jan. 2019
    Zuletzt bearbeitet: 13 Jan. 2019
    @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.
     
  16. stulle

    stulle Neuer User

    Registriert seit:
    8 Jan. 2006
    Beiträge:
    11
    Zustimmungen:
    1
    Punkte für Erfolge:
    3
    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.
     
  17. CaptainMorgan

    CaptainMorgan Neuer User

    Registriert seit:
    28 Nov. 2015
    Beiträge:
    127
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    #17 CaptainMorgan, 13 Jan. 2019
    Zuletzt bearbeitet: 13 Jan. 2019
    @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.
     
  18. Shirocco88

    Shirocco88 Aktives Mitglied

    Registriert seit:
    4 Jan. 2016
    Beiträge:
    868
    Zustimmungen:
    65
    Punkte für Erfolge:
    28
    #18 Shirocco88, 13 Jan. 2019
    Zuletzt bearbeitet: 13 Jan. 2019
    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).
     
  19. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,788
    Zustimmungen:
    665
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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"):
    Code:
    --- 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.
     
    syncron gefällt das.
  20. CaptainMorgan

    CaptainMorgan Neuer User

    Registriert seit:
    28 Nov. 2015
    Beiträge:
    127
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    #20 CaptainMorgan, 13 Jan. 2019
    Zuletzt bearbeitet: 13 Jan. 2019
    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:
    Code:
        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