[GRASS-dev] [GRASS GIS] #735: r.in.wms causes g.parser buffer owerflow

#735: r.in.wms causes g.parser buffer owerflow
-------------------------+--------------------------------------------------
Reporter: marisn | Owner: grass-dev@lists.osgeo.org
     Type: defect | Status: new
Priority: normal | Milestone: 6.5.0
Component: Raster | Version: svn-develbranch6
Keywords: | Platform: Linux
      Cpu: Unspecified |
-------------------------+--------------------------------------------------
I used r.in.wms to download high resolution topographical maps from local
WMS service. Download part went just fine but it resulted into 287 tiles.
Then r.in.wms calls r.in.gdalwarp
input=/home/maris/grassdata/wms_download/topo_10k_psrs_0.png and so on 287
tile names. Such call results in buffer owerflow in g.parser:

{{{
*** buffer overflow detected ***: g.parser terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x37)[0x7f017d0107e7]
/lib/libc.so.6[0x7f017d00e5c0]
/lib/libc.so.6[0x7f017d00d8b9]
/lib/libc.so.6(_IO_default_xsputn+0x85)[0x7f017cf9a935]
/lib/libc.so.6(_IO_vfprintf+0x35b4)[0x7f017cf6e1f4]
/lib/libc.so.6(__vsprintf_chk+0x9d)[0x7f017d00d95d]
/lib/libc.so.6(__sprintf_chk+0x80)[0x7f017d00d8a0]
g.parser(main+0x458)[0x401668]
/lib/libc.so.6(__libc_start_main+0xe6)[0x7f017cf46a26]
g.parser[0x401099]
======= Memory map: ========
00400000-00403000 r-xp 00000000 08:06 10052434
/home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-gnu/bin/g.parser
00602000-00603000 r--p 00002000 08:06 10052434
/home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-gnu/bin/g.parser
00603000-00604000 rw-p 00003000 08:06 10052434
/home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-gnu/bin/g.parser
01169000-0118a000 rw-p 00000000 00:00 0
[heap]
7f017cb0e000-7f017cb23000 r-xp 00000000 08:02 834485
/lib64/libgcc_s.so.1
7f017cb23000-7f017cd22000 ---p 00015000 08:02 834485
/lib64/libgcc_s.so.1
7f017cd22000-7f017cd23000 r--p 00014000 08:02 834485
/lib64/libgcc_s.so.1
7f017cd23000-7f017cd24000 rw-p 00015000 08:02 834485
/lib64/libgcc_s.so.1
7f017cd24000-7f017cd26000 r-xp 00000000 08:02 294652
/lib64/libdl-2.10.1.so
7f017cd26000-7f017cf26000 ---p 00002000 08:02 294652
/lib64/libdl-2.10.1.so
7f017cf26000-7f017cf27000 r--p 00002000 08:02 294652
/lib64/libdl-2.10.1.so
7f017cf27000-7f017cf28000 rw-p 00003000 08:02 294652
/lib64/libdl-2.10.1.so
7f017cf28000-7f017d079000 r-xp 00000000 08:02 294677
/lib64/libc-2.10.1.so
7f017d079000-7f017d279000 ---p 00151000 08:02 294677
/lib64/libc-2.10.1.so
7f017d279000-7f017d27d000 r--p 00151000 08:02 294677
/lib64/libc-2.10.1.so
7f017d27d000-7f017d27e000 rw-p 00155000 08:02 294677
/lib64/libc-2.10.1.so
7f017d27e000-7f017d283000 rw-p 00000000 00:00 0
7f017d283000-7f017d305000 r-xp 00000000 08:02 294683
/lib64/libm-2.10.1.so
7f017d305000-7f017d504000 ---p 00082000 08:02 294683
/lib64/libm-2.10.1.so
7f017d504000-7f017d505000 r--p 00081000 08:02 294683
/lib64/libm-2.10.1.so
7f017d505000-7f017d506000 rw-p 00082000 08:02 294683
/lib64/libm-2.10.1.so
7f017d506000-7f017d51a000 r-xp 00000000 08:02 830733
/lib64/libz.so.1.2.3
7f017d51a000-7f017d719000 ---p 00014000 08:02 830733
/lib64/libz.so.1.2.3
7f017d719000-7f017d71a000 r--p 00013000 08:02 830733
/lib64/libz.so.1.2.3
7f017d71a000-7f017d71b000 rw-p 00014000 08:02 830733
/lib64/libz.so.1.2.3
7f017d71b000-7f017d723000 r-xp 00000000 08:06 10052200
/home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-
gnu/lib/libgrass_datetime.6.5.svn.so
7f017d723000-7f017d922000 ---p 00008000 08:06 10052200
/home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-
gnu/lib/libgrass_datetime.6.5.svn.so
7f017d922000-7f017d923000 r--p 00007000 08:06 10052200
/home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-
gnu/lib/libgrass_datetime.6.5.svn.so
7f017d923000-7f017d924000 rw-p 00008000 08:06 10052200
/home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-
gnu/lib/libgrass_datetime.6.5.svn.so
7f017d924000-7f017d978000 r-xp 00000000 08:06 10052212
/home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-
gnu/lib/libgrass_gis.6.5.svn.so
7f017d978000-7f017db77000 ---p 00054000 08:06 10052212
/home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-
gnu/lib/libgrass_gis.6.5.svn.so
7f017db77000-7f017db78000 r--p 00053000 08:06 10052212
/home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-
gnu/lib/libgrass_gis.6.5.svn.so
7f017db78000-7f017db7a000 rw-p 00054000 08:06 10052212
/home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-
gnu/lib/libgrass_gis.6.5.svn.so
7f017db7a000-7f017db81000 rw-p 00000000 00:00 0
7f017db81000-7f017db9e000 r-xp 00000000 08:02 294369
/lib64/ld-2.10.1.so
7f017dc10000-7f017dd70000 r--p 00000000 08:02 505020
/usr/lib64/locale/locale-archive
7f017dd70000-7f017dd73000 rw-p 00000000 00:00 0
7f017dd8a000-7f017dd91000 r--s 00000000 08:02 489490
/usr/lib64/gconv/gconv-modules.cache
7f017dd91000-7f017dd99000 r--p 00000000 08:06 10420339
/home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-
gnu/locale/lv/LC_MESSAGES/grassmods.mo
7f017dd9a000-7f017dd9d000 rw-p 00000000 00:00 0
7f017dd9d000-7f017dd9e000 r--p 0001c000 08:02 294369
/lib64/ld-2.10.1.so
7f017dd9e000-7f017dd9f000 rw-p 0001d000 08:02 294369
/lib64/ld-2.10.1.so
7fff55c2f000-7fff55c47000 rw-p 00000000 00:00 0
[stack]
7fff55cf8000-7fff55cf9000 r-xp 00000000 00:00 0
[vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
[vsyscall]
Aborted

}}}

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/735&gt;
GRASS GIS <http://grass.osgeo.org>

#735: r.in.wms causes g.parser buffer owerflow
---------------------+------------------------------------------------------
  Reporter: marisn | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: normal | Milestone: 6.5.0
Component: Raster | Version: svn-develbranch6
Resolution: | Keywords:
  Platform: Linux | Cpu: Unspecified
---------------------+------------------------------------------------------
Comment (by glynn):

Replying to [ticket:735 marisn]:

> I used r.in.wms to download high resolution topographical maps from
local WMS service. Download part went just fine but it resulted into 287
tiles. Then r.in.wms calls r.in.gdalwarp
input=/home/maris/grassdata/wms_download/topo_10k_psrs_0.png and so on 287
tile names. Such call results in buffer owerflow in g.parser:

I can fix the buffer overflow by using G_asprintf(), but some operating
systems aren't going to like storing that much data in an environment
variable (Linux 2.6 doesn't mind, but a limit of 4K for argv+environ is
quite common).

The Python scripting library in GRASS 7 has g.parser write the information
to stdout rather than using environment variables, so this isn't an issue
there.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/735#comment:1&gt;
GRASS GIS <http://grass.osgeo.org>

#735: r.in.wms causes g.parser buffer owerflow
---------------------+------------------------------------------------------
  Reporter: marisn | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: normal | Milestone: 6.5.0
Component: Raster | Version: svn-develbranch6
Resolution: | Keywords:
  Platform: Linux | Cpu: Unspecified
---------------------+------------------------------------------------------
Comment (by hamish):

from grass65/scripts/r.in.wms/wms.request:

{{{
   g.message "Requesting ${NUMBER_OF_TILES} tiles."
   if [ "$NUMBER_OF_TILES" -gt 200 ] ; then
      g.message -w "Proceed with care. This number of tiles may exceed \
        the maximum command line argument length available from your \
        operating system and cause an error later on in the r.in.gdalwarp \
        step. In addition it may be considered abusive behavior by the \
        server provider - check their terms of use."
   fi
}}}

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/735#comment:2&gt;
GRASS GIS <http://grass.osgeo.org>

#735: r.in.wms causes g.parser buffer owerflow
---------------------+------------------------------------------------------
  Reporter: marisn | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: normal | Milestone: 6.5.0
Component: Raster | Version: svn-develbranch6
Resolution: | Keywords:
  Platform: Linux | Cpu: Unspecified
---------------------+------------------------------------------------------
Comment (by hamish):

one trick is try to make the tiles bigger with the maxcols, maxcols so you
need to get fewer tiles. Note many servers will restrict this size.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/735#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>

#735: r.in.wms causes g.parser buffer owerflow
---------------------+------------------------------------------------------
  Reporter: marisn | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: normal | Milestone: 6.5.0
Component: Raster | Version: svn-develbranch6
Resolution: | Keywords:
  Platform: Linux | Cpu: Unspecified
---------------------+------------------------------------------------------
Comment (by marisn):

Replying to [comment:2 hamish]:
> from grass65/scripts/r.in.wms/wms.request:
>
> {{{
> g.message "Requesting ${NUMBER_OF_TILES} tiles."
> }}}
g.message is a bad choice, as on fast machine with fast WMS server it too
soon gets burried in >200 tile downloading messages.

Glynn: no idea. It's too hardcore for me. Still IMHO buffer owerflow isn't
the right way how to deal with error conditions.

It would be nice if r.in.wms could calculate resulting arg length and fail
if it exceeds systems capabilities (theoretical limits).

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/735#comment:4&gt;
GRASS GIS <http://grass.osgeo.org>