[PATCH] Fix readdir_r with long file names

[Rich Felker]

On Mon, Jun 10, 2013 at 07:17:59PM -0400, Carlos O'Donell wrote:
> On 06/10/2013 03:20 AM, Florian Weimer wrote:
> > On 06/07/2013 04:41 PM, Rich Felker wrote:
> >> Yes. I just disagree with recommending that portable applications
> >> use readdir_r (as discussed on the Austin Group tracker/list, it
> >> has major problems related to NAME_MAX not being mandatory) and
> >> with the idea (by someone else, not you) to add a readdir4 rather
> >> than just deprecating caller-provided buffers for reading
> >> directories. Those were the only things I was commenting on.
> > 
> > Carlos, what do you think about this?  I tend to agree with Rich here
> > and would like to back out this part of your suggestions again.
>  
> I'm OK with backing out the recommendation of readdir_r as a portable
> alternative, but the text should instead say *why* readdir_r is not 
> a good portable alternative. That is to say we should specifically
> dissuade the use if that's actually the truth.

I think the text should be informative and objective rather than
dogmatic. It should include the following information:

- On systems where NAME_MAX is not defined, readdir_r cannot be used
  safely, as the interface contract for readdir_r is specified in
  terms of NAME_MAX.

- On systems where NAME_MAX is defined but not enforced for all
  filesystems, there may be directory entries whose names are readable
  by readdir but not readdir_r, and attempts to read such names on
  older versions of glibc may result in exploitable buffer overflows.

- Historically, POSIX does not require readdir to be thread-safe, but
  on most (all?) known recent systems including glibc-based ones, it
  is thread-safe as long as the same directory stream (DIR*) is not
  accessed concurrently from multiple threads.

- Future versions of POSIX will mandate this level of thread-safety
  for the readdir function and mark readdir_r obsolescent.

If this is deemed "too technical", perhaps someone could write a short
summary that expresses the tradeoffs between the two interfaces. It
would be especially useful to know if my "all?" above really is "all
recent systems" or even "all historical implementations", since it
would make the choice for application developers much more clear-cut.

Rich