[Mono-bugs] [Bug 82678][Maj] Changed - Mono_Posix_Syscall_readdir_r causes stack corruption in readdir_r, resulting in crash

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by jonpryor at vt.edu.

http://bugzilla.ximian.com/show_bug.cgi?id=82678

--- shadow/82678	2007-09-03 20:20:00.000000000 -0400
+++ shadow/82678.tmp.4872	2007-09-03 20:30:17.000000000 -0400
@@ -130,6 +130,28 @@
 dirent)', and malloc(3) _that_ size.  (Though pathconf(3) may not have
 a value for _PC_PATH_MAX -- you'd have to check.)
 
 Is there any source indicating that the character array is the
 preferred approach, despite no mention of this "hack" from the actual
 Unix03 standard for readdir_r()?
+
+------- Additional Comments From jonpryor at vt.edu  2007-09-03 20:30 -------
+And having read the URL you refer to...
+
+My suggestion to use pathconf(3) seems to be somewhat suspect, as it's
+an attack vector (if an attacker changes the filesystem from
+underneath you).
+
+Which pretty much points out that this is an impossible to solve this
+problem from user code, as there's no way to know how large a buffer
+to allocate (consider GNU Hurd which is supposed to have no filename
+limits), no way to safely determine this at runtime, and NO
+documentation in the standard readdir_r() docs to suggest that any of
+this is the case.
+
+In short readdir_r() is horribly broken UNLESS the local libc
+implementation ensures that `struct dirent' contains a local buffer
+that is large enough to hold the maximum path length for that platform
+(which pretty much kills any chance of "no limits").
+
+So I'm still left with not liking the proposed solution and apparently
+unable to accept what should be standard code. :-(