On 3/25/18 10:38 AM, Herbert Xu wrote:
The native version of expandmeta allocates a buffer that may be
overrun for two reasons. First of all the size is 1 byte too small
but this is normally hidden because the minimum size is rounded
up to 2048 bytes. Secondly, if the directory level is deep enough,
any buffer can be overrun.
This patch fixes both problems by calling realloc when necessary.
This was already the case before your patch, but on systems that flat
out reject paths longer than PATH_MAX (that includes GNU/Linux), it
seems weird that expansion can produce paths which then don't work.
Test case:
cd /tmp
x=xxxxxxxxxxxxxxxxx
x=$x$x$x$x$x$x$x$x$x$x$x$x$x$x$x
ln -s . $x
set -- $x/$x/$x/$x/$x/$x/$x/$x/$x/$x/$x/$x/$x/$x/$x/$x/$x*
case $1 in
*"*") echo "no match" ;;
*) if test -e "$1"
then echo "match and exists"
else echo "match but does not exist"
fi ;;
esac
rm $x
I'm seeing "no match" from bash/mksh/pdksh/posh/yash/zsh, but "match but
does not exist" from dash/bosh/ksh93. Other commands would naturally
print the "File name too long" error.
Should the buffer perhaps simply be limited to PATH_MAX, taking care to
just give up if something longer is found? That could avoid the need to
handle reallocations and result in somewhat smaller and simpler code.
The downside would be that if other systems do support paths longer than
PATH_MAX, globbing would no longer work for those paths.
Cheers,
Harald van Dijk
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
