Re: expand: Fix buffer overflow in expandmeta

[Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>]

On Mon, Mar 26, 2018 at 03:03:38AM +0200, Harald van Dijk wrote:
>
> 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.

PATH_MAX only applies in certain cases.  Besides, you can always
cd into the directories one level at a time to circumvent it.

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

Well the fact is that all systems allow paths to exist which are
longer than PATH_MAX.  Besides, even if we did impose a limit here
we'd still have to check that limit at every recursion level which
means that the code won't be that much simpler.

Cheers,
-- 
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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