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
| ||
|
Date: Mon Nov 7 12:32:26 2005 From: andfarm at gmail.com (Andrew Farmer) Subject: Re: readdir_r considered harmful On 06 Nov 05, at 01:00, Casper.Dik@....COM wrote: >> 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. > In practice, you're correct. In theory, however, consider the following code path. > THREAD 1 THREAD 2 > ------------------------------ ------------------------------ > DIR *d1 = opendir(dir1); > DIR *d2 = opendir(dir2); > dent1 = readdir(dir1); > dent2 = readdir(dir2); > use(dent1); > In most implementations, dent1 != dent2. HOWEVER, there is no guarantee that they will not both point to the same statically allocated buffer, and some implementations may do so. For example, this is why ctime_r exists: ctime returns a pointer to a statically allocated buffer, and hence is not thread safe. You are correct, though, that the glibc implementation of readdir is thread-safe, so readdir_r is unnecessary in all common situations. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051106/94cb3af3/PGP.bin
Powered by blists - more mailing lists