.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. olistudent

    olistudent IPPF-Urgestein

    Registriert seit:
    19 Okt. 2004
    Beiträge:
    14,777
    Zustimmungen:
    10
    Punkte für Erfolge:
    38
    Beruf:
    Softwareentwickler
    Ort:
    Kaiserslautern
    Ja. Nach einem make vsftpd-dirclean sollte das nächste make das Paket neu auspacken und den Patch anwenden.

    Gruß,
    Oliver
     
  2. CaptainMorgan

    CaptainMorgan Neuer User

    Registriert seit:
    28 Nov. 2015
    Beiträge:
    117
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    Habe nun auch vorher vsftpd-dirclean angewandt, die Fehlermedlung bleibt die gleiche wie in #20.
     
  3. Shirocco88

    Shirocco88 Aktives Mitglied

    Registriert seit:
    4 Jan. 2016
    Beiträge:
    806
    Zustimmungen:
    56
    Punkte für Erfolge:
    28
    #23 Shirocco88, 13 Jan. 2019
    Zuletzt bearbeitet: 13 Jan. 2019
    das sieht ggf. nach mit UNIX-EOL vs. DOS-EOL Problem aus ?
    wie hast Du die Datei make/vsftpd/patches/121-no_libcap.patch
    in der Freetz-VM erstellt ?

    Bitte mal folgende Befehl eingeben
    Code:
    file make/vsftpd/patches/121-no_libcap.patch
    Bei Ausgabe von:
    Code:
    make/vsftpd/patches/121-no_libcap.patch: ASCII text, with CRLF line terminators


    kann die erforderlich Konvertierung durch Eingabe von
    Code:
    fromdos make/vsftpd/patches/121-no_libcap.patch
    durchgeführt werden.
     
  4. CaptainMorgan

    CaptainMorgan Neuer User

    Registriert seit:
    28 Nov. 2015
    Beiträge:
    117
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    Ich bin mir ziemlich sicher dass ich die nicht persönlich erstellt habe.
    Aber ich bin mir sicher dass ich es irgendwo veranlasst habe.
    Allerdings habe ich sie auch nie editiert. Solange EOL noch für End of Line steht sollte die genauso sein wie sie von github kommt.
    Den 900....*.patch habe ich mit Notepad++ erstellt, Windows (CR LF) und UTF-8.
     
  5. Shirocco88

    Shirocco88 Aktives Mitglied

    Registriert seit:
    4 Jan. 2016
    Beiträge:
    806
    Zustimmungen:
    56
    Punkte für Erfolge:
    28
    Das sieht nach DOS-/WINDOWS EOL statt UNIX-EOL aus;
    Bitte mal auf UNIX-EOL sowie ASCII statt UTF-8 umstellen und testen.
     
  6. CaptainMorgan

    CaptainMorgan Neuer User

    Registriert seit:
    28 Nov. 2015
    Beiträge:
    117
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    Das geht ja schlag auf Schlag, habe deinen Edit eben verpasst:
    Code:
    [email protected]:~/freetz-trunk-7560$ file make/vsftpd/patches/121-no_libcap.patch
    make/vsftpd/patches/121-no_libcap.patch: unified diff output, ASCII text
    [Code]
    
    Die Ausgabe die du für schädlich erachtest taucht aber beim eigentlich neuen Patch auf:
    [Code]
    [email protected]:~/freetz-trunk-7560$ file make/vsftpd/patches/900-ignore_munmap_error.patch
    make/vsftpd/patches/900-ignore_munmap_error.patch: unified diff output, ASCII text, with CRLF line terminators
    
    Soll ich fromdos dann mal auf diesen Patch anwenden?
    Edit: Wir tippen wirlich synchron, hole jetzt #25 nach.
    Edit2: Gesagt getan:
    Code:
    [email protected]:~/freetz-trunk-7560$ fromdos make/vsftpd/patches/900-ignore_munmap_error.patch
    [email protected]:~/freetz-trunk-7560$ file make/vsftpd/patches/900-ignore_munmap_error.patch
    make/vsftpd/patches/900-ignore_munmap_error.patch: unified diff output, ASCII text
    
    Der Fehler bleibt trotz erneutem make vsftp-dirclean der gleiche.
     
  7. Shirocco88

    Shirocco88 Aktives Mitglied

    Registriert seit:
    4 Jan. 2016
    Beiträge:
    806
    Zustimmungen:
    56
    Punkte für Erfolge:
    28
    #27 Shirocco88, 13 Jan. 2019
    Zuletzt bearbeitet: 13 Jan. 2019
    Bitte mal folgendes eingeben:
    Code:
    ls -la make/vsftpd/patches/900-ignore_munmap_error.patch
    cat make/vsftpd/patches/900-ignore_munmap_error.patch

    und in CODE-Tags posten.
     
  8. CaptainMorgan

    CaptainMorgan Neuer User

    Registriert seit:
    28 Nov. 2015
    Beiträge:
    117
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    Sehr gerne:
    Code:
    [email protected]:~/freetz-trunk-7560$ ls -la make/vsftpd/patches/900-ignore_munmap_error.patch
    -rw-r--r-- 1 freetz freetz 1556 Jan 13 18:22 make/vsftpd/patches/900-ignore_munmap_error.patch
    [email protected]:~/freetz-trunk-7560$ cat make/vsftpd/patches/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);
    
    Edit: Konvertierung zu ANSI (subset von ASCII wenn ich mich nich irre)
    Code:
    [email protected]:~/freetz-trunk-7560$ file make/vsftpd/patches/900-ignore_munmap_error.patch
    make/vsftpd/patches/900-ignore_munmap_error.patch: unified diff output, ASCII text
    
    Leider selbes Ergebnis.
     
  9. Shirocco88

    Shirocco88 Aktives Mitglied

    Registriert seit:
    4 Jan. 2016
    Beiträge:
    806
    Zustimmungen:
    56
    Punkte für Erfolge:
    28
    Bitte mal "./fmake -c vsftpd-precompiled" eingeben
    und die Datei fmake.log als Attachement anhängen;
    dann sieht man mehr;

    ich habe gerade keine Freetz-VM zur Hand, kann es also nicht selbst nachstellen.
     
  10. CaptainMorgan

    CaptainMorgan Neuer User

    Registriert seit:
    28 Nov. 2015
    Beiträge:
    117
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    Gerne.
     

    Anhänge:

  11. Shirocco88

    Shirocco88 Aktives Mitglied

    Registriert seit:
    4 Jan. 2016
    Beiträge:
    806
    Zustimmungen:
    56
    Punkte für Erfolge:
    28
    das sieht so aus, als fehlen 2 Zeilen im Patchfile in #28
    Code:
    tail -2 make/vsftpd/patches/900-ignore_munmap_error.patch
    +}
    +
    
    Bitte prüfen/korrigieren.
     
  12. CaptainMorgan

    CaptainMorgan Neuer User

    Registriert seit:
    28 Nov. 2015
    Beiträge:
    117
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    So läuft make zumindest mal durch.
    Aber eine Bemerkung kann sich die Toolchain nicht verkneifen:
    Code:
    ....
        applying patch file make/vsftpd/patches/900-ignore_munmap_error.patch
        patching file sysutil.c
        patching file secbuf.c
        Hunk #1 succeeded at 14 with fuzz 1.
        patch unexpectedly ends in middle of line
        ----------------------------------------------------------------------
    .....
    
    
    Bei Dateien erfolgreich gepatcht, aber ein abruptes Ende.
    Kann ich das guten Gewissens einspielen oder sollte man dem auf den Grund gehen?
     
  13. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,629
    Zustimmungen:
    633
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Hier mal das Patch-File als Anhang (die Endung muß aber auf dem Build-Host dann ".patch" lauten) - da sind die richtigen Zeilenenden enthalten und die Datei ist komplett:
    Code:
    [email protected]:~/freetz> make vsftpd-dirclean
    rm -f -r source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3
    rm -f -r packages/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3; rm -f packages/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/.vsftpd packages/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/.vsftpd-3.0.3;
    [email protected]:~/freetz> make vsftpd-source
    ---> package/vsftpd: preparing... mkdir -p source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3; tools/gunzip -c dl/vsftpd-3.0.3.tar.gz | tools/tar-gnu -x -C source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3 --transform='s|^./\+||' --strip-components=1
    set -e; shopt -s nullglob; for i in make/vsftpd/patches/*.patch; do tools/freetz_patch source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3 $i; done;
        applying patch file make/vsftpd/patches/0005-whitespaces.debian.patch
        patching file parseconf.c
        patching file str.c
        patching file str.h
        patching file sysutil.c
        patching file sysutil.h
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/0006-greedy.debian.patch
        patching file ls.c
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/0007-utf8.debian.patch
        patching file features.c
        patching file parseconf.c
        patching file tunables.c
        patching file tunables.h
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/0010-remote-dos.debian.patch
        patching file sysdeputil.c
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/0050-CVE-2015-1419.debian.patch
        patching file ls.c
        patching file str.c
        patching file str.h
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/100-freetz_paths.patch
        patching file tunables.c
        patching file defs.h
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/101-respect_freetz_largfiles_flags.patch
        patching file sysutil.c
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/102-anonym_root.patch
        patching file secutil.c
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/110-destdir.patch
        patching file Makefile
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/111-find_libs.patch
        patching file Makefile
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/120-enable_ssl.patch
        patching file builddefs.h
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/121-no_libcap.patch
        patching file sysdeputil.c
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/900-ignore_uninitialized_secbuf.patch
        patching file sysutil.c
        patching file secbuf.c
        ----------------------------------------------------------------------
    [email protected]:~/freetz>
    
     

    Anhänge:

  14. CaptainMorgan

    CaptainMorgan Neuer User

    Registriert seit:
    28 Nov. 2015
    Beiträge:
    117
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    Ich habe vsftdp wieder static und mit ssl support gewählt.
    Die Toolchain ist problemlos und zügig durchgelaufen.
    Das ganze ist auch stabil, bei vsftpd zeigt sich aber weiterhin das gleiches Verhalten.
    Ohne SSL 500:OOPS munmap, mit SSL GnuTLS-Fehler-15: An unexpected TLS packet was received.
     
  15. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,629
    Zustimmungen:
    633
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Also ich bin jetzt eine geschlagene Stunde durch die vsftpd-Quellen gekrochen und finde keine (plausible) Erklärung, an welcher Stelle ansonsten noch ein "munmap()" aufgerufen wird bzw, wo es ansonsten noch ein "die("munmap");" geben würde.

    Ehe ich noch weitere Zeit investiere, hätte ich ganz gerne das Protokoll der Übersetzung des fraglichen "vsftpd" - da sollte man dann die Anwendung des Patches auch erkennen können.

    Ansonsten hege ich nämlich den Verdacht, daß der einfach so (wie er oben angehangen ist) als "txt"-Datei gespeichert und daher beim Build gar nicht berücksichtigt wurde - das ist (nach dem, was ich in den Quellen gefunden habe) im Moment jedenfalls die plausibelste Vermutung.

    Liege ich damit falsch, gebe ich (hier beim "vsftpd") auf ... dann habe ich keine Idee mehr, wo dieser Aufruf von "munmap()" herkommen sollte (der in "filestr.c" kann es in diesem Zustand der FTP-Verbindung auch nicht sein) und eine weitere Suche ergibt keinen Sinn.

    Anders als das TLS-Problem kann man den ersten Fehler nämlich auch wirklich "suchen" in den Quellen ... für den zweiten braucht es (dem Text der Fehlermeldung nach) ja den Empfang des fehlerhaften/unerwarteten Paketes. Wobei man auch da ja einfach mal auf OpenSSL ausweichen könnte ... bei identischem Fehlerbild liegt das Problem dann vermutlich im "vsftpd", ansonsten halt im verwendeten TLS-Stack. Wenn das Problem schon vor dem erfolgreichen Login auftritt, sofern man eine TLS-Verbindung verwenden will, ist es ja auch kein Wunder (bzw. sollte es niemanden wirklich überraschen), wenn das Problem mit dem "500 OOPS", das ja ohne TLS auch erst nach dem Login auftritt, bei einer TLS-Verbindung nicht vorkommt, weil die schon vorher "abkackt".

    Es wäre also nützlich, sich bei der "Fehlerbetrachtung" zunächst mal auf ein Problem zu konzentrieren und da das "500 OOPS" wohl deutlich hinter dem TLS-Zeug liegt und ohne seine Lösung auch eine Behebung des TLS-Problems wenig Sinn ergibt (sofern das Ziel ein funktionierender Daemon ist), beginne ich halt (sofern es überhaupt weitergehen sollte, weil die Ursache des "keine Veränderung" gefunden wird) mit dem Problem, was (vermutlich) beiden Zweigen (mit und ohne TLS) gemeinsam ist.

    Erst dann, wenn mit dem "vsftpd" ohne TLS auch eine erfolgreiche Datenübertragung (nach Login) möglich ist, macht es irgendeinen Sinn, sich dem nächsten Problem zu widmen ... es ist jedenfalls äußerst unwahrscheinlich, daß das TLS-Problem und der "munmap()"-Fehler dieselbe Ursache haben und selbst wenn das so wäre, würde man die mit dem "500 OOPS"-Problem ja auch schon beseitigen.
     
  16. CaptainMorgan

    CaptainMorgan Neuer User

    Registriert seit:
    28 Nov. 2015
    Beiträge:
    117
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    #36 CaptainMorgan, 14 Jan. 2019
    Zuletzt bearbeitet: 14 Jan. 2019
    Da darf ich verneinen. Habe die Datei als *.patch hochgeladen.
    Hier ist noch eine Log von heute (Auszug im Spoiler (vom - meiner bescheidenen Meinung nach - relevanten Teil, komplette Variante im Anhang) habe den Patch seit gestern Nacht nicht angerührt, und ich bin mir sicher dass die Log auch da genauso aussah. Bei diesem Image habe ich den SSL Support wieder abgewählt. Ansonsten sind die Einstellungen identisch. Das nun erzeugte Image teste ich auch noch, sobald ich die Box entbehren kann.

    Code:
    [email protected]:~$ cd freetz-trunk-7560
    [email protected]:~/freetz-trunk-7560$ make vsftpd-dirclean
    rm -f -r source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.                                                                                                                                                             3
    rm -f -r packages/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.                                                                                                                                                             0.3; rm -f packages/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/.vsftpd                                                                                                                                                              packages/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/.vsftpd-3.0.3;
    [email protected]:~/freetz-trunk-7560$ make menuconfig
    
    
    *** End of the configuration.
    *** Execute 'make' to start the build or try 'make help'.
    
    [email protected]:~/freetz-trunk-7560$ make
    Dateien /home/freetz/freetz-trunk-7560/source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/.vsftpd_config.temp und /home/freetz/freetz-trunk-7560/source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/.vsftpd_config sind verschieden.
    mkdir -p packages/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/root
    if test -d make/vsftpd/files; then      tools/tar-gnu -cf - -C make/vsftpd/files --exclude=.svn --exclude=.gitignore --exclude=.build-prereq-checked --exclude=.unpacked --exclude=.configured --exclude=.compiled --exclude=.installed . | tools/tar-gnu -xf - -C packages/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3; fi
    ---> package/vsftpd: preparing... mkdir -p source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3; tools/gunzip -c dl/vsftpd-3.0.3.tar.gz | tools/tar-gnu -x -C source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3 --transform='s|^./\+||' --strip-components=1
    set -e; shopt -s nullglob; for i in make/vsftpd/patches/*.patch; do tools/freetz_patch source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3 $i; done;
        applying patch file make/vsftpd/patches/0005-whitespaces.debian.patch
        patching file parseconf.c
        patching file str.c
        patching file str.h
        patching file sysutil.c
        patching file sysutil.h
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/0006-greedy.debian.patch
        patching file ls.c
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/0007-utf8.debian.patch
        patching file features.c
        patching file parseconf.c
        patching file tunables.c
        patching file tunables.h
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/0010-remote-dos.debian.patch
        patching file sysdeputil.c
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/0050-CVE-2015-1419.debian.patch
        patching file ls.c
        patching file str.c
        patching file str.h
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/100-freetz_paths.patch
        patching file tunables.c
        patching file defs.h
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/101-respect_freetz_largfiles_flags.patch
        patching file sysutil.c
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/102-anonym_root.patch
        patching file secutil.c
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/110-destdir.patch
        patching file Makefile
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/111-find_libs.patch
        patching file Makefile
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/120-enable_ssl.patch
        patching file builddefs.h
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/121-no_libcap.patch
        patching file sysdeputil.c
        ----------------------------------------------------------------------
        applying patch file make/vsftpd/patches/900-ignore_uninitialized_secbuf.patch
        patching file sysutil.c
        patching file secbuf.c
        ----------------------------------------------------------------------
    cmd() { PATH="/home/freetz/freetz-trunk-7560/toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/bin:/home/freetz/freetz-trunk-7560/toolchain/build/mips_gcc-5.5.0/mips-unknown-linux-gnu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin" LD_RUN_PATH="/usr/lib/freetz" FREETZ_LIBRARY_DIR="/usr/lib/freetz" make -j2  "[email protected]"  || { printf "\n\\033[33m%s\\033[m\n" "ERROR: Build failed.";  exit 1; } };       if [ -e source/.echo_item_start -a ! -e source/.echo_item_build ]; then echo -n "building... "; touch source/.echo_item_build; fi; cmd -C source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3 \
            CC="/home/freetz/freetz-trunk-7560/toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/bin/mips-linux-uclibc-gcc" \
            CFLAGS="-march=34kc -mtune=34kc -msoft-float -Os -pipe -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 " \
            LDFLAGS=" -static" \
            EXTRA_LIBS=""
    building... make[1]: Verzeichnis „/home/freetz/freetz-trunk-7560/source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3“ wird betreten
    
    

    Ich hoffe das ist mit der Log geschehen, ansonsten brauche ich einen Hinweis wie man das Kompilieren detailierter protokoliert.

    Sollte der Fehler aber im Dateisystem oder in der Benutzerverwaltung liegen, könnte vsftpd eventuell aus "Verlegenheit" oder Zufall "500 OOPS: munmap" auswerfen. Der Grund dafür kann evtl. ebenso TLS durcheinander gebracht haben, entweder beim Kompilieren oder in der Box. Oder die munmap Fehlermeldung wird bei Verschlüsselung nicht richtig durchgereicht.

    Ich bin aber ganz deiner Meinung, zuerst muss es unverschlüsselt funktionieren, ich halte es aber für möglich dass das Lösen eines Problems beide löst.

    Edit:
    Der Gedanke rührt daher, dass das Anmelden mit anonymus zu 100 % funktioniert, mit erstellten Benutzern vielleicht zu 5%. anonymous hat zwar kein Homedirectory, aber der Login klappt.
    Wenn ich Lokale Benutzer aktiviere klappt noch nicht einmal der Login mit Root, 500 munmaps.
    Die Kombination aus anonymous und TLS funktioniert aus offensichtlichen Gründen nicht.
     

    Anhänge:

  17. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,629
    Zustimmungen:
    633
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    #37 PeterPawn, 14 Jan. 2019
    Zuletzt bearbeitet: 14 Jan. 2019
    Ja, da ist der Patch dann tatsächlich dabei ... das hinterläßt mich eben einigermaßen ratlos, woher das nun kommen mag.

    Wenn Du das weiter testen möchtest (und würdest), könnte ich noch ein paar andere Patches versuchen, um überhaupt erst mal die Stelle einzukreisen, wo dieses Problem am Ende auftritt. Die "munmap()"-Aufrufe gibt es (nach "grep"-Aussagen) nur an dieser einen Stelle:
    Code:
    [email protected]:~/freetz> grep -n -r munmap source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/seccompsandbox.c:298:  allow_nr(__NR_munmap);
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/Changelog:247:- Tuning: eliminate 3 mprotect(), 1 munmap() and 1 mmap() system call per
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/Changelog:1328:- Seccomp filter sandbox: missing munmap() -- oops. Did you know that qsort()
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/sysutil.h:159:void vsf_sysutil_memunmap(void* p_start, unsigned int length);
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/sysutil.c:1146:vsf_sysutil_memunmap(void* p_start, unsigned int length)
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/sysutil.c:1148:  int retval = munmap(p_start, length);
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/sysutil.c:1151:    die("munmap");                                         <<< hier kommt das "500 OOPS: munmap" her
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/sysutil.c:1156:vsf_sysutil_memunmap_noerror(void* p_start, unsigned int length)
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/sysutil.c:1158:  int retval = munmap(p_start, length);
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/secbuf.c:18:void vsf_sysutil_memunmap_noerror(void*, unsigned int);
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/secbuf.c:90:  vsf_sysutil_memunmap(p_mmap, map_size);
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/secbuf.c:116:  vsf_sysutil_memunmap_noerror(p_mmap, map_size);
    [email protected]:~/freetz>
    
    und das ist diese Funktion:
    Code:
    void vsf_sysutil_memunmap(void* p_start, unsigned int length)
    {
      int retval = munmap(p_start, length);
      if (retval != 0)
      {
        die("munmap");
      }
    }
    
    Also kann der Absturz nur beim Aufruf dieser Funktion erfolgen und davon gibt es auch nur genau eine Stelle (im originalen Code, denn der "_noerror"-Fall ist ja von ersten Patch-Versuch):
    Code:
    [email protected]:~/freetz> grep -n -r vsf_sysutil_memunmap source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/sysutil.h:159:void vsf_sysutil_memunmap(void* p_start, unsigned int length);
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/sysutil.c:1146:vsf_sysutil_memunmap(void* p_start, unsigned int length)
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/sysutil.c:1156:vsf_sysutil_memunmap_noerror(void* p_start, unsigned int length)
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/secbuf.c:18:void vsf_sysutil_memunmap_noerror(void*, unsigned int);
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/secbuf.c:90:  vsf_sysutil_memunmap(p_mmap, map_size);
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/secbuf.c:116:  vsf_sysutil_memunmap_noerror(p_mmap, map_size);
    [email protected]:~/freetz>
    
    Diese Funktion (vsf_sysutil_memunmap) wird dann also wieder genau an einer einzigen anderen Stelle aufgerufen und das ist die Funktion zum Freigeben so eines "secure buffers" in "secbuf.c":
    Code:
    void
    vsf_secbuf_free(char** p_ptr)
    {
      unsigned int map_size;
      unsigned long page_offset;
      char* p_mmap = *p_ptr;
      unsigned int page_size = vsf_sysutil_getpagesize();
      if (p_mmap == 0)
      {
        return;
      }
      /* 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(p_mmap, map_size);
    }
    
    Da kommt der gesamte "vsftpd" also nur dann hin, wenn irgendjemand irgendwo "vsf_secbuf_free" aufruft und das ist genau an zwei Stellen der Fall (eine davon ist die weiter vorne schon erwähnte automatische Freigabe eines alten Mappings):
    Code:
    [email protected]:~/freetz> grep -n -r vsf_secbuf_free source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/filestr.c:57:  vsf_secbuf_free(&p_sec_buf);
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/secbuf.h:17:/* vsf_secbuf_free()
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/secbuf.h:24:void vsf_secbuf_free(char** p_ptr);
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/secbuf.c:17:void vsf_secbuf_free_noerror(char**);
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/secbuf.c:30:  vsf_secbuf_free_noerror(p_ptr);
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/secbuf.c:68:vsf_secbuf_free(char** p_ptr)
    source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/vsftpd-3.0.3/secbuf.c:94:vsf_secbuf_free_noerror(char** p_ptr)
    [email protected]:~/freetz>
    
    Da bleibt also nur die Stelle, die ich schon gepatcht habe oder die Datei "filestr.c", die so aussieht:
    Code:
    /*
     * Part of Very Secure FTPd
     * Licence: GPL v2
     * Author: Chris Evans
     * filestr.c
     *
     * This file contains extensions to the string/buffer API, to load a file
     * into a buffer.
     */
    
    #include "filestr.h"
    /* Get access to "private" functions */
    #define VSFTP_STRING_HELPER
    #include "str.h"
    #include "sysutil.h"
    #include "secbuf.h"
    #include "utility.h"
    
    int
    str_fileread(struct mystr* p_str, const char* p_filename, unsigned int maxsize)
    {
      int fd;
      int retval = 0;
      filesize_t size;
      char* p_sec_buf = 0;
      struct vsf_sysutil_statbuf* p_stat = 0;
      /* In case we fail, make sure we return an empty string */
      str_empty(p_str);
      fd = vsf_sysutil_open_file(p_filename, kVSFSysUtilOpenReadOnly);
      if (vsf_sysutil_retval_is_error(fd))
      {
        return fd;
      }
      vsf_sysutil_fstat(fd, &p_stat);
      if (vsf_sysutil_statbuf_is_regfile(p_stat))
      {
        size = vsf_sysutil_statbuf_get_size(p_stat);
        if (size > maxsize)
        {
          size = maxsize;
        }
        vsf_secbuf_alloc(&p_sec_buf, (unsigned int) size);
    
        retval = vsf_sysutil_read_loop(fd, p_sec_buf, (unsigned int) size);
        if (vsf_sysutil_retval_is_error(retval))
        {
          goto free_out;
        }
        else if ((unsigned int) retval != size)
        {
          die("read size mismatch");
        }
        str_alloc_memchunk(p_str, p_sec_buf, (unsigned int) size);
      }
    free_out:
      vsf_sysutil_free(p_stat);
      vsf_secbuf_free(&p_sec_buf);
      vsf_sysutil_close(fd);
      return retval;
    }
    
    Diese Funktion liest halt irgendeine Datei in den Speicher als Zeichenkette und benutzt diesen "secure buffer" nur als Zwischenlager (das Ergebnis wird dann mittels "str_alloc_memchunk" in einen anderen Speicherbereich kopiert) - sprich, er wird hinterher bzw. im Falle eines Fehlers auch gleich wieder freigegeben. Dabei kann eigentlich auch kein Problem auftreten ... die einzige Chance wäre eine Datei der Länge 0, die dann auch zum "vsf_secbuf_alloc()" mit Länge 0 führen würde.

    Da liegt dann vielleicht auch wieder der Fehler ... eine Behandlung, daß bei Dateilänge 0 der ganze Zinnober nicht stattfindet, ist in "str_fileread()" nicht zu sehen. Das wäre dann also doch noch eine andere Idee (insofern war die Info, daß es mit "anonymous" (der ja nirgendwo in einer "/etc/passwd" o.ä. steht) funktioniert, dann tatsächlich wichtig - wenn es diesmal die Ursache des Problems sein sollte).

    Ich baue mal einen Patch für das Umgehen einer Datei der Länge 0 ... jetzt schicke ich das hier aber doch erst mal ab, weil mir ständig irgendein JS-Script etwas von "blocked" erzählen will und ich den bisherigen Text schon gerne gerettet hätte.

    EDIT: Das nenne ich mal "overblocking" ... wenn ich oben die Sterne beim FTP-Benutzernamen oder beim Dateinamen in "/etc" weglasse und das "ausschreibe", dann lehnt irgendein dämlicher Content-Checker bei CloudFlare die Übertragung ab.
    EDIT2: Nun geht's doch ... und ich wollte noch einen Screenshot machen. :-(

    Egal, weiter im Text ... den alten Patch einfach vergessen (Löschen reicht) und ich melde mich, wenn ich einen neuen habe.
     
  18. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,629
    Zustimmungen:
    633
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    #38 PeterPawn, 14 Jan. 2019
    Zuletzt bearbeitet: 14 Jan. 2019
    Wie sieht's mit diesem Patch aus?

    Der kann nun erst recht nichts schaden ... ganz im Gegenteil. Wenn die Datei tatsächlich die Länge 0 hat, werden jede Menge nutzloser Operationen übersprungen, denn die Länge 0 hat die erwartete Zeichenkette auch schon zu diesem Zeitpunkt.
     

    Anhänge:

  19. CaptainMorgan

    CaptainMorgan Neuer User

    Registriert seit:
    28 Nov. 2015
    Beiträge:
    117
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    #39 CaptainMorgan, 14 Jan. 2019
    Zuletzt bearbeitet: 14 Jan. 2019
    Keinerlei Verbesserung.
    Die Toolchain ist wieder reibungslos durchgelaufen, aber erneut munmap.
    Ich teste auch mittlerweile einfach mit root als ftpuser.
    Kann ich vsftpd denn auch in der Linux VM ausführen, oder kann jemand anderes meine kompilierte Binary in eine kompatible FritzBox einspeisen?

    Edit: Ich habe auch noch die 7320 mit 7330SL-7.01-15014 mit vsftpd, wo kein Patch eingespielt wurde.
    Erzeugt in der gleichen Linux Umgebung. Ich habe zwar nur die 6 MB übrig zum Testen, aber es funktionieren und 100% aller LogIns und alle Dateiübetragungen.
    Auf der 7362SL und auf der 7560 hingegen gibt es identische Fehler.
    Wie ich es verstanden habe unterscheiden sich die drei Modelle in der hinsicht dass die 763SL und 7560 NOR Modelle sind und die 7320 NAND Flash hat. Außerdem haen die 7362und 7560 ein neueres AVM OS. Kann es vielleicht einfach sein dass sich am Kernel grundlegen unterscheidet?
    Könnte das vielleicht mal jemand überprüfen?
    So ist es schwierig zu unterscheiden ob ich jedesmal den gleichen Fehler mache, oder ob es wirklich ein Problem im Code gibt.
     
  20. Shirocco88

    Shirocco88 Aktives Mitglied

    Registriert seit:
    4 Jan. 2016
    Beiträge:
    806
    Zustimmungen:
    56
    Punkte für Erfolge:
    28
    ich habe mal den SuFu nach vsftpd: fix '500 OOPS: munmap' angeworfen
    und folgenden Patch/Fix gefunden:

    https://code.aliyun.com/yaoruisheng/k2-router/commit/c6d26bc2d67ec86ebdf222afc3997c469e9ad4e1

    Code:
     cat 901-ignore_munmap_error.patch
    --- secbuf.c    2008-02-02 02:30:41.000000000 +0100
    +++ secbuf.c    2019-01-14 20:00:38.265565570 +0100
    @@ -51,7 +51,8 @@
        */
       *((unsigned int*)p_mmap) = round_up;
       p_no_access_page = p_mmap;
    -  vsf_sysutil_memprotect(p_no_access_page, page_size, kVSFSysUtilMapProtNone);
    +  /* fix issue with MIPS SCACHE on MT7621 (and no sense to hide value of mapped block size) */
    +  vsf_sysutil_memprotect(p_no_access_page, page_size, kVSFSysUtilMapProtReadOnly);
    
       p_mmap += page_size;
       if (page_offset)
    
    evtl. hilft es auch hier;

    Hinweis: die Datei 901-ignore_munmap_error.patch ist statt 900-ignore_munmap_error.patch anzuwenden
     

    Anhänge: