Re: nftw miscalculates FTW.base when pathnames end in /

[Rich Felker <dalias@libc.org>]

On Wed, May 04, 2016 at 03:42:19PM +0200, Joakim Sindholt wrote:
> Running the test program from the glibc ftw man page[1]:
> 
> +zhasha@wirbelwind /home/zhasha ; ./6.out test
> d    0    4096   test                                     0 test
> d    1    4096   test/a                                   5 a
> f    2       0   test/a/1                                 7 1
> d    1    4096   test/b                                   5 b
> f    2       0   test/b/1                                 7 1
> f    2       0   test/b/2                                 7 2
> d    1    4096   test/ddd                                 5 ddd
> f    2       0   test/ddd/5                               9 5
> d    1    4096   test/cc                                  5 cc
> f    2       0   test/cc/3                                8 3
> +zhasha@wirbelwind /home/zhasha ; ./6.out test/
> d    0    4096   test/                                    4 /
> d    1    4096   test/a                                   6
> f    2       0   test/a/1                                 7 1
> d    1    4096   test/b                                   6
> f    2       0   test/b/1                                 7 1
> f    2       0   test/b/2                                 7 2
> d    1    4096   test/ddd                                 6 dd
> f    2       0   test/ddd/5                               9 5
> d    1    4096   test/cc                                  6 c
> f    2       0   test/cc/3                                8 3
> 
> The final 2 columns are the file name length and path + ftw->base
> respectively, which is off by one when the path ends in /. It also
> seems to confuse the initial dir name.
> 
> I have attached a fix but I'm not sure it's a particularly good one.
> 
> [1] http://linux.die.net/man/3/ftw

> diff --git a/src/misc/nftw.c b/src/misc/nftw.c
> index efb2b89..7c2c0d3 100644
> --- a/src/misc/nftw.c
> +++ b/src/misc/nftw.c
> @@ -108,11 +108,13 @@ int nftw(const char *path, int (*fn)(const char *, const struct stat *, int, str
>  	if (fd_limit <= 0) return 0;
>  
>  	l = strlen(path);
> +	while (l && path[l-1]=='/') --l;
>  	if (l > PATH_MAX) {
>  		errno = ENAMETOOLONG;
>  		return -1;
>  	}
> -	memcpy(pathbuf, path, l+1);
> +	memcpy(pathbuf, path, l);
> +	pathbuf[l]='\0';
>  	
>  	pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &cs);
>  	r = do_nftw(pathbuf, fn, fd_limit, flags, NULL);

Thanks for reminding me to look at this today. I've actually read the
code, and while your patch should avoid the problem, I agree it's
probably not the right fix (interpreting and alterring the part of the
path passed by the application). Instead, I think the error is in the
computations of new.base and lev.base.

new.base should be equal to the offset at which de->d_name is pasted
into the buffer, which is j+1, not l+1; these only differ when path
ends in a slash.

lev.base is computed separately depending on whether or not there's a
previous history; for the no-history case, it should be computed by
skipping all trailing slashes, then backing up until the previous
slash or beginning of string, whichever is hit first. But rather than
special-casing !h in do_nftw, the top-level nftw function should
probably set up a fake "-1 level" history structure to pass in. This
gathers the special top-level logic all in one place.

Can you try these ideas and see if they work for you? If not I'll give
them a try soon, but I've got a few other things I need to do first.

Rich