full-disclosure - Re: readdir_r considered harmful

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <200511060900.jA690qDk001066@vaticaan.Holland.Sun.COM>
Date: Sun Nov  6 16:01:01 2005
From: Casper.Dik at Sun.COM (Casper.Dik@....COM)
Subject: Re: readdir_r considered harmful 

>Then you never really understood the implementation, seems.  Of course
>all implementations keep the content of the directory as read with
>getdents or so in the DIR descriptor.  But it is usually not the case
>that the whole content fits into the buffer allocated.  One could, of
>course, resize the buffer to fit the content of the directory read,
>even if this means reserving hundreds or thousands of kBs.  But this
>is not how most implementations work.

I don't see how that is relevant; the typical use of readdir() is as follows:

	DIR *dirp = opendir(name);

	while ((dent = readdir(dirp)) != NULL) {
		...
	}

	closedir(dirp);

Nothing other threads do with readdir() on different dirp's will influence
what "dent" points to.

I have *never* seen a program where multiple threads read from a single
dirp; and I can't image the use.

>Instead implementations keep work similar to every buffered file I/O
>operation.  But this means that buffer content is replaced.  If this
>happens and some thread uses readdir() instead of readdir_r(), the
>returned string pointer suddenly becomes invalid since it points to
>memory which has been replaced.

Yes, the next call to readdir() *on the same dirp* may change what
the previous call; but that's completely irrelevant for most uses
of readdir().

Of course, an application may want to save all readdir() return values,
but that is completely orthogonal to threads; there is no reason
why the POSIX *thread* specification includes readdir_r().

>Next time, before you make such comments, ask Don Cragun to explain
>things to you.

Next time before you mail, you might want to engage your brain.

There is NO reason for a thread-safe library to use readdir_r() over
readdir(), with common readdir() implementations.

Casper