Non WMS call on WMS-T layer leads to DOS situation

[akrherz]

I have the WMS-T used as an example on the website (docs/en/ogc/wms_time.html) . :)

The tileindex table in the PostGIS database contains 1.5 million rows!

When a non-WMS request is made against the Mapserver service, Mapserver ends up querying the database table without any time filter, thus returning and parsing all 1.5 million rows. Running shp2img reveals this code path:

[Tue Jun  2 13:13:53 2009].979977 msPostGISLayerOpen called: the_geom from nexrad_n0r_tindex
[Tue Jun  2 13:13:53 2009].980001 msPostGISLayerOpen: No connection in pool, creating a fresh one.
[Tue Jun  2 13:13:54 2009].30535 msConnPoolRegister(time_idx,dbname=postgis host=iemdb user=nobody,0x1309c9f0)
[Tue Jun  2 13:13:54 2009].30606 msPostGISLayerFreeItemInfo called.
[Tue Jun  2 13:13:54 2009].30656 msPostGISLayerWhichShapes called.
[Tue Jun  2 13:13:54 2009].30701 msPostGISParseData called.
[Tue Jun  2 13:13:54 2009].30752 msPostGISRetrievePK called.
[Tue Jun  2 13:13:54 2009].30798 msPostGISRetrievePK: select attname from pg_attribute, pg_constraint, pg_class where pg_constraint.conrelid = pg_class.oid and pg_class.oid = pg_attribute.attrelid and pg_constraint.contype = 'p' and pg_constraint.conkey[1] = pg_attribute.attnum and pg_class.relname = 'nexrad_n0r_tindex' and pg_table_is_visible(pg_class.oid) and pg_constraint.conkey[2] is null
[Tue Jun  2 13:13:54 2009].49280 msPostGISRetrievePK: No results found.
[Tue Jun  2 13:13:54 2009].49364 msPostGISParseData: unique_column=oid, srid=, geom_column_name=the_geom, table_name=nexrad_n0r_tindex
[Tue Jun  2 13:13:54 2009].49413 msPostGISBuildSQL called.
[Tue Jun  2 13:13:54 2009].49450 msPostGISBuildSQLItems called.
[Tue Jun  2 13:13:54 2009].49487 msPostGISBuildSQLItems: 0 items requested.
[Tue Jun  2 13:13:54 2009].49523 msPostGISBuildSQLFrom called.
[Tue Jun  2 13:13:54 2009].49568 msPostGISBuildSQLWhere called.
[Tue Jun  2 13:13:54 2009].49605 msPostGISBuildSQLSRID called.
[Tue Jun  2 13:13:54 2009].49639 msPostGISBuildSQLSRID: Building find_srid line.
[Tue Jun  2 13:13:54 2009].49673 msPostGISBuildSQLSRID: Found table (nexrad_n0r_tindex)
[Tue Jun  2 13:13:54 2009].49710 msPostGISBuildSQLBox called.
[Tue Jun  2 13:13:54 2009].49798 msPostGISLayerWhichShapes query: select encode(AsBinary(force_collection(force_2d("the_geom")),'NDR'),'base64') as geom,"oid" from nexrad_n0r_tindex where the_geom && GeomFromText('POLYGON((-126 13.6815144766147,-126 60.3184855233853,-66 60.3184855233853,-66 13.6815144766147,-126 13.6815144766147))',find_srid('','nexrad_n0r_tindex','the_geom'))
[Tue Jun  2 13:14:34 2009].90600 msPostGISLayerWhichShapes query status: 2
[Tue Jun  2 13:14:34 2009].90718 msPostGISLayerWhichShapes got 1516126 records in result.

Perhaps this isn't really a bug, but expected behaviour.

Now to figure out how to package this as a testcase :)

Thanks for all your help and sorry about my annoying behaviour on IRC :(

[akrherz]

testcase files

[akrherz]

shp2img -all_debug 3 -o test.png -m wmst.map

shows the fun :), thanks

[dmorissette]

Maybe there should be a setting for a default time value that would be applied when performing regular (non-WMS-T) requests?

[akrherz]

any further thoughts on this? I occasionally have an end user foul something up and cause troubles on the server end. My server farm nodes all have more memory now, so the impacts of this aren't too significant. thanks

[pramsey]

Perhaps embed a LIMIT statement in the SQL of your PostGIS data line. It seems like a larger failing of the WMS-T spec/implementation than the PostGIS module. Like Daniel says, there should probably be a default (or option to configure one).

[dmorissette]

I believe MapServer handles time support by setting the FILTER parameter of the given layer based on the TIME WMS parameter from the request.

Did you consider setting a default FILTER in your layer to be some default valid TIME value? If no TIME is set in the WMS request (or if the request is not WMS) then this default FILTER will end up being used, otherwise MapServer should override it with the TIME value from the request.

Assefa, can you please confirm that this would be a valid way to handle this issue?

[assefa]

Daniel, It is correct with the following additional note:

• If the problem is with WMS requests and time parameter is not in the request, you could probably set the wms_timedefault parameter (http://mapserver.org/ogc/wms_time.html).

[akrherz]

Thanks for your comments... Daniel's workaround by setting a default "FILTER" did work. I previously had wms_timedefault set and that did not prevent the DOS.

daryl

[dmorissette]

Thank you for confirming the workaround Daryl.

Turning this into a Doc bug. Jeff, could you please add something to the ogc/wms_time.html doc explaining that when setting up a WMS service with time support it is recommended to set a FILTER on the layer(s) that support time which sets a default time value that will apply when non-MWS requests are made (through the traditional CGI or MapScript)... this would be in addition to setting wms_timedefault which applies for WMS uses.

[havatv]

I have tried to fix this for 6.0 and trunk documentation in r12498 and r12499 by adding the following to the wms_time document.

It is also recommended to set a :ref:`LAYER` `FILTER` for the time
layer to provide a default time also for non-WMS requests.  If the
time item is `mytime`, and the time format is "YYYYMMDD" the following
layer filter could be used:

.. code-block:: mapfile

  FILTER ([mytime] = '2004-01-01 14:10:00')

I also added the following filters to the examples:

    FILTER ([TIME]='2004-01-01 14:10:00')

    FILTER ([datetime] = "2006-06-23T03:10:00Z")

Please check if it is OK - expressions confuse me, and I have no experience with time expressions and wms.