This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix readdir_r with long file names
- From: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: kosaki dot motohiro at gmail dot com, Carlos O'Donell <carlos at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 06 Jun 2013 17:06:32 -0400
- Subject: Re: [PATCH] Fix readdir_r with long file names
- References: <519220C7 dot 6050705 at redhat dot com> <20130516110136 dot GB11420 at spoyarek dot pnq dot redhat dot com> <5194CDEE dot 4020708 at redhat dot com> <20130516125029 dot GE11420 at spoyarek dot pnq dot redhat dot com> <5194D697 dot 8040106 at redhat dot com> <20130516130952 dot GA16952 at spoyarek dot pnq dot redhat dot com> <519B58EC dot 6060108 at redhat dot com> <51B0A2F9 dot 5060004 at redhat dot com> <51B0B39F dot 4060202 at redhat dot com> <51B0BD36 dot 3030202 at redhat dot com> <CAHGf_=r9Rz63pho+84ORk0a_oDyJSj-MCnZ56uPrT3L6sVEfeQ at mail dot gmail dot com> <51B0F1DD dot 5070901 at redhat dot com>
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().