[464] in bugtraq
Re: 8lgm's SCO "at" hole
daemon@ATHENA.MIT.EDU (John Nemeth)
Sun Dec 11 19:47:40 1994
Date: Sun, 11 Dec 1994 15:48:44 -0800
From: John Nemeth <jnemeth@cue.bc.ca>
In-Reply-To: Casper Dik <casper@fwi.uva.nl>
"Re: 8lgm's SCO "at" hole" (Dec 11, 2:15pm)
To: Casper Dik <casper@fwi.uva.nl>
Cc: bugtraq@fc.net
On Dec 11, 2:15pm, Casper Dik wrote:
} Subject: Re: 8lgm's SCO "at" hole
}
} >On Dec 10, 2:22pm, Casper Dik wrote:
} >} Subject: Re: 8lgm's SCO "at" hole
} >}
} >} Getwd() is to getcwd() what gets() is to fgets() [ well, almost ].
} >}
} >} When chosing between: getwd(char *buf) and getcwd(char *buf, size_t
} >} size_of_buf) the choice should be obvious.
} >
} > I would have to disagree. fgets() can return any amount of data
} >(potentially GB if connected to a socket or very large file); whereas,
} >getwd() won't return anything bigger then MAXPATHLEN, so buf can be
} >sized appropriately.
}
} Almost true, and definitely true for binaries that ship with the system.
} But lets pick a nit:
}
} What happens when some future version of Unix increases the MAXPATHLEN
} manifest constant?
Okay, point taken.
} But agreed, getwd() is currently not a problem. Getcwd is the preferred
} interface anyway (on modern systems :-)
The problem is that getcwd() often does a popen("/bin/pwd", ...);
which isn't safe in a setuid program, so I would consider getwd() to
be preferable until getcwd() does something sensible. Why can't
/bin/pwd be turned into a library routine, or is it simply too big?
} I've only seen something like this break once, bonus points for who
} can tell why the following is wrong:
}
} 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.
}-- End of excerpt from Casper Dik
