[41050] in bugtraq

home help back first fref pref prev next nref lref last post

Re: readdir_r considered harmful

daemon@ATHENA.MIT.EDU (Casper.Dik@Sun.COM)
Sat Nov 5 15:34:13 2005

Message-Id: <200511051845.jA5IjKDk007734@vaticaan.Holland.Sun.COM>
From: Casper.Dik@Sun.COM
To: Ben Hutchings <ben@decadentplace.org.uk>
Cc: bugtraq@securityfocus.com, full-disclosure@lists.grok.org.uk
In-Reply-To: <20051101035703.GH27885@decadentplace.org.uk> 
Date: Sat, 05 Nov 2005 19:45:20 +0100


>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

home help back first fref pref prev next nref lref last post