[Problem] vsftpd funktioniert nicht mehr - mehr Verbose

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
Ja. Nach einem make vsftpd-dirclean sollte das nächste make das Paket neu auspacken und den Patch anwenden.

Gruß,
Oliver
 
Habe nun auch vorher vsftpd-dirclean angewandt, die Fehlermedlung bleibt die gleiche wie in #20.
 
CaptainMorgan schrieb:
Code: 
tripping trailing CRs from patch; use --binary to disable.
Zum Vergrößern anklicken....
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.
 
Zuletzt bearbeitet:
Shirocco88 schrieb:
wie hast Du die Datei make/vsftpd/patches/121-no_libcap.patch
in der Freetz-VM erstellt ?
Zum Vergrößern anklicken....
Ich bin mir ziemlich sicher dass ich die nicht persönlich erstellt habe.
Shirocco88 schrieb:
mit UNIX-EOL oder DOS-EOL ?
Zum Vergrößern anklicken....
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.
 
CaptainMorgan schrieb:
Den 900....*.patch habe ich mit Notepad++ erstellt, Windows (CR LF) und UTF-8.
Zum Vergrößern anklicken....

CaptainMorgan schrieb:
Code: 
    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:
Zum Vergrößern anklicken....
Das sieht nach DOS-/WINDOWS EOL statt UNIX-EOL aus;
Bitte mal auf UNIX-EOL sowie ASCII statt UTF-8 umstellen und testen.
 
Das geht ja schlag auf Schlag, habe deinen Edit eben verpasst:
Shirocco88 schrieb:
Bitte mal folgende Befehl eingeben
Code: 
file make/vsftpd/patches/121-no_libcap.patch
Zum Vergrößern anklicken....

Code: 
freetz@Freetz-Server:~/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]
freetz@Freetz-Server:~/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: 
freetz@Freetz-Server:~/freetz-trunk-7560$ fromdos make/vsftpd/patches/900-ignore_munmap_error.patch
freetz@Freetz-Server:~/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.
 
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.
 
Zuletzt bearbeitet:
Sehr gerne:
Code: 
freetz@Freetz-Server:~/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
freetz@Freetz-Server:~/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: 
freetz@Freetz-Server:~/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.
 
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.
 
CaptainMorgan schrieb:
Code: 
----------------------------------------------------------------------
applying patch file make/vsftpd/patches/900-ignore_munmap_error.patch
patching file sysutil.c
patching file secbuf.c
patch unexpectedly ends in middle of line
patch: **** malformed patch at line 65:  
----------------------------------------------------------------------
Zum Vergrößern anklicken....

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.
 
Shirocco88 schrieb:
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.
Zum Vergrößern anklicken....
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?
 
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: 
freetz@zbox:~/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;
freetz@zbox:~/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
    ----------------------------------------------------------------------
freetz@zbox:~/freetz>
 

Anhänge

  • 900-ignore_uninitialized_secbuf.patch.txt
    1.5 KB · Aufrufe: 4
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.
 
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.
 
PeterPawn schrieb:
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.
Zum Vergrößern anklicken....

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: 
freetz@Freetz-Server:~$ cd freetz-trunk-7560
freetz@Freetz-Server:~/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;
freetz@Freetz-Server:~/freetz-trunk-7560$ make menuconfig


*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.

freetz@Freetz-Server:~/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  "$@"  || { 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

PeterPawn schrieb:
Protokoll der Übersetzung des fraglichen "vsftpd"
Zum Vergrößern anklicken....

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

PeterPawn schrieb:
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.
Zum Vergrößern anklicken....

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

  • .config.compressed.txt
    595 Bytes · Aufrufe: 2
  • .config.txt
    65.1 KB · Aufrufe: 0
  • make.log.txt
    40.8 KB · Aufrufe: 2
Zuletzt bearbeitet:
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: 
freetz@zbox:~/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);
freetz@zbox:~/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: 
freetz@zbox:~/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);
freetz@zbox:~/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: 
freetz@zbox:~/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)
freetz@zbox:~/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.
 
Zuletzt bearbeitet:
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

  • 900-handle_empty_files.patch.txt
    341 Bytes · Aufrufe: 9
Zuletzt bearbeitet:
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.
 
Zuletzt bearbeitet:
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

  • 901-ignore_munmap_error.patch.txt
    502 Bytes · Aufrufe: 6
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 601 (Mitglieder: 34, Gäste: 567)

Neueste Beiträge

Statistik des Forums

Themen
244,827
Beiträge
2,219,029
Mitglieder
371,520
Neuestes Mitglied
immrmud
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück