This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix readdir_r with long file names


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().



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]