> On Thu, Oct 21, 1999 at 03:05:22PM -0500, Rami Dass wrote: > > > Also, I beleive that this problem occurs only in certain OS's vulnerable > > to the getcwd() exploit, the ERRATA file, in the 2.6.0 source tree, lists > > them: > > > > "Systems needing getcwd(): ... > > OSF/1 (osf) ... Gregory A Lundberg <lundbergat_private> states: > It's a well-known fact that getwd() is not a good choice; it overruns > buffers. getcwd() allows bounds checking and should be used instead. > > The systems listed above have no getcwd() function, or at least nobody has > reported those systems now have one, so we're still assuming they do not > (notice we're fixing _that_ class of assumptions by switching to autoconf). > Sun operating systems, in particular SunOS, provide the getcwd() function. > Testing has shown the results from that function are not reliable. Digital UNIX from 4.0b (uname -rsv - OSF1 V4.0 564) does have getcwd() as does Solaris 7 (2.7). Furthermore even if one does use getwd(), it has the following feature in both Solaris and in OSF/1 (DUNIX 4.0b): OSF/1 The maximum pathname length, in characters, is set by the PATH_MAX defini- tion, as specified in the limits.h file. If the length of the pathname of the current directory is greater than (PATH_MAX + 1), including the null byte, getwd() fails and returns a null pointer. Solaris If the length of the pathname of the current working direc- tory is greater than ({PATH_MAX} + 1) including the null byte, getwd() fails and returns a null pointer.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:08:51 PDT