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: "Carlos O'Donell" <carlos at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 6 Jun 2013 15:53:16 -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>
+#ifdef NAME_MAX
+ if (reclen > offsetof (DIRENT_TYPE, d_name) + NAME_MAX + 1)
+ {
+ /* The record is very long. It could still fit into the
+ caller-supplied buffer if we can skip padding at the
+ end. */
+ size_t namelen = strlen(dp->d_name);
+ if (namelen <= NAME_MAX)
+ reclen = offsetof (DIRENT_TYPE, d_name) + namelen + 1;
+ else
+ {
+ /* The name is too long. Ignore this file. */
+ dirp->errcode = ENAMETOOLONG;
+ dp->d_ino = 0;
+ continue;
+ }
+ }
+#endif
Hmm...
Linux man pages say:
>Since POSIX.1 does not specify the size of the d_name field, and other
>nonstandard fields may precede that field within the dirent structure, portable
>applications that use readdir_r() should allocate the buffer whose address is
>passed in entry as follows:
>
> name_max = pathconf(dirpath, _PC_NAME_MAX);
> if (name_max == -1) /* Limit not defined, or error */
> name_max = 255; /* Take a guess */
> len = offsetof(struct dirent, d_name) + name_max + 1;
> entryp = malloc(len);
> (POSIX.1 requires that d_name is the last field in a struct dirent.)
So, only broken applications may hit this? If so, do you really think such
broken application checks return code correctly?
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.
I mean, portable applications should use readdir_r correctly and Linux specific
one should use readdir instead.
Side note: the above man page is not a theoretical issue. At least, Solaris
requires it.
Am I missing something?