[468] in bugtraq
Re: 8lgm's SCO "at" hole
daemon@ATHENA.MIT.EDU (John Nemeth)
Mon Dec 12 00:44:09 1994
Date: Sun, 11 Dec 1994 19:47:45 -0800
From: John Nemeth <jnemeth@cue.bc.ca>
In-Reply-To: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
"Re: 8lgm's SCO "at" hole" (Dec 11, 9:53pm)
To: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
Cc: bugtraq@fc.net
On Dec 11, 9:53pm, der Mouse wrote:
} Subject: Re: 8lgm's SCO "at" hole
}
} >> select(getdtablesize(), &readfds, &writefds, &exceptfds, &timeout);
} > getdtablesize() doesn't exist on all systems and can return very very
} > large numbers on systems that have dynamically allocated file tables.
}
} That was (part of) my reaction too...but that's not the real point.
} Think about what the first note was talking about: MAXPATHLEN
} increasing, so in the future getwd() might construct and (try to)
} return a string longer than the statically allocated buffer whose size
} was fixed when the application was compiled: essentially, a clash
} between compiling now and executing in the future after system changes.
}
} Now go back and look at that select() call again, with that in mind :-)
I just read the manpage for select() and I can't see where
getwd() or MAXPATHLEN enters into it; although, there is the
possibility that getdtablesize() returns different values in
different versions of the OS. (especially if the OS switches
from a non-dynamically allocated to a dynamically allocated file
table. This latter trick has nailed a few programs that were
being ported to NetBSD.
}-- End of excerpt from der Mouse
