[PATCH] Fix readdir_r with long file names

KOSAKI Motohiro kosaki.motohiro@gmail.com
Thu Jun 6 21:06:00 GMT 2013


>> So, only broken applications may hit this? If so, do you really think such
>> broken application checks return code correctly?
>
> There's precedent for my approach in realpath, where we don't use
> pathconf(path, _PC_PATH_MAX), either, but cap the path length at PATH_MAX.

PATH_MAX is used VFS as hard coded limitations. So, I don't think any Linux filesystem
have a long path exceed PATH_MAX.

And, to be honest, I didn't think any Linux filesystem can have >256 len path
components until I saw your email. Could you please tell us which filesystem
allow such long file name if you can disclose?


>> If a fuse filesystem which allow >256 file names is legal, this patch
>> breaks
>> right applications. In the other hands, if it is illegal, I'd suggest
>> to fix such broken filesystems instead.
>
>
> Hmm.  We could fix the file systems and patch all affected applications to
> use the approach from the manual page, with s/pathconf/fpathconf/ to avoid
> the race, and a hard failure on failure ("take a guess" is a very bad idea
> here).

I don't want to talk pathconf vs fpathconf thing. But I completely agree you
are right. All applications should use fpathconf instead of pathconf.


> For some reason, I discarded that approach.  Probably I didn't know about
> the f_namemax member of fstatvfs at the time (and I didn't look at the
> fpathconf implementation).  f_namemax is wrong for the file systems in
> question, but that could be fixed.
>
> We'd still have to patch readdir_r to pass through long file names.

I guess the right way is to fix a filesystem instead glibc because 1) your
patch assume >256 is illegal and if so, there is no reason not to fix a source
of trouble. 2) adding new error code may bring us new application breakage.
Is it impossible? Or Are these file system unfixable lots?


> The best approach would be a readdir4 function which takes an explicit size
> argument.  A bit unsual would be a newdirent function which returns a
> suitably sized dirent object, based on a DIR *.

Right.

readdir_r considered harmful <http://womble.decadent.org.uk/readdir_r-advisory.html> says
the same conclusion.

Or, drepper suggests to use readdir() instead. http://udrepper.livejournal.com/18555.html
Because "readdir_r considered harmful" afraid readdir() is not thread safe, but it is, at
least, all of i observed modern platforms. I recently almost always use readdir().




More information about the Libc-alpha mailing list