> 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 <[EMAIL PROTECTED]> 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.
