[PATCH] Fix readdir_r with long file names

[Florian Weimer]

On 05/16/2013 01:01 PM, Siddhesh Poyarekar wrote:
> On Tue, May 14, 2013 at 01:32:23PM +0200, Florian Weimer wrote:
>> This patch changes readdir_r to return ENAMETOOLONG if the kernel
>> returns a file name longer than NAME_MAX characters, after the end of
>> the directory has been reached (so that the directory contents is not
>> truncated).  It also makes the padding compensation code
>> architecture-agnostic and enables it everywhere.
>
> The specification for readdir/readdir_r does not mention ENAMETOOLONG
> as a possible error return[1], so this should at least be mentioned in
> the glibc manual, if not also in the man page.  So a manual patch is
> needed on top of this.

Thanks for your comments.

We could use EOVERFLOW instead.  But ENAMETOOLONG is more informative.

I updated the documentation in the new version of the patch, and made it 
more clear that readdir is the recommended interface.

> Also, I don't think returning an error at the end of the traversal is
> very useful.  If we're adding an extension, we might as well go the
> whole way and define something more useful: if the errno returned is
> ENAMETOOLONG, then the directory can still be traversed and subsequent
> readdir calls are still valid.  At least one knows the position at
> which the error occurred.  This obviously makes the add-on
> documentation even more important to highlight the difference.

I think you really have to stop on the first error, otherwise you can 
end up with an endless loop (e.g., if the kernel reports a very 
low-level error such as EIO/ENXIO).

> This could be consolidated with the if/else above it, so that it looks
> like:
>
>    if (dp != NULL)
>      {
>        *result = memcpy (entry, dp, reclen);
> #ifdef _DIRENT_HAVE_D_RECLEN
>        entry->d_reclen = reclen;
> #endif
>        ret = 0;
>      }
>    else
>      {
>        *result = NULL;
>        ret = dirp->errorcode;
>      }

Done.

> Finally, you need to change rewinddir to reset errorcode.

Good point.

Please have a look at the updated version.

-- 
Florian Weimer / Red Hat Product Security Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: glibc-readdir_r.patch
Type: text/x-patch
Size: 8871 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20130516/fbe405bb/attachment.bin>