| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <200511051845.jA5IjKDk007734@vaticaan.Holland.Sun.COM> Date: Sat, 05 Nov 2005 19:45:20 +0100 From: Casper.Dik@....COM To: Ben Hutchings <ben@...adentplace.org.uk> Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com Subject: Re: readdir_r considered harmful >The Austin Group should amend POSIX and the SUS in one or more of the >following ways: > >1. Standardise the dirfd function from BSD and recommend its use in > determining the buffer size for readdir_r. >2. Specify a new variant of readdir in which the buffer size is explicit > and the function returns an error code if the buffer is too small. >3. Specify that NAME_MAX must be defined as the length of the longest > name that can be used on any filesystem. (This seems to be what many > or most implementations attempt to do at present, although POSIX > currently specifies otherwise.) Why not: 4. Require the readdir() implementation to use state local to dirp. I've never understood the rationale behind readdir_r; it's like someone went through the manual looking for "pointers to static locations" and defined new functions with _r for each of them, suspending thinking. But perhaps people can look at how their readdir() implementations behave. The Solaris implementation appears to be "unshared dirp safe". Casper _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists