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: <B52D4580-FF15-4096-A2D1-C725C3B0F833@gmail.com>
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