[mapserver-dev] Motion: Adopt RFC 62 - Support Additional WFS GetFeature Output Formats

Frank Warmerdam warmerdam at pobox.com
Tue Oct 12 11:47:40 EDT 2010

Lime, Steve D (DNR) wrote:
> That's cool. It does force folks to ponder security. A couple ones I came up
> with (now that I have thought about it more):
> - divulging data unintentionally (same issue exists with GML and is
> mitigated through metadata) 


Yes, this is potentially an issue but I believe one has to take some
steps to expose a layer through WFS and the default is to not make any
of the fields available.  So I think we have taken a restrictive policy
already with the map developer having to take steps to expose data.

> - excessive memory consumption for large
> datasets compiled in memory. I've no idea if this is real or not since I
> don't know how GDAL works.

There are definately denial of service possibilities which can be mitigated
to some extend by limits of the number of features per request.  I deliberately
kept the STORAGE=filesystem option to avoid assembling the resultset in
memory which could consume a lot of resources.  I must confess that the
current logic has the .zip (when using FORMAT=zip) assembled in memory always
though I could have it also honour the STORAGE parameter if so desired.  That
should make it possible to harden things such that there is never very much
kept in RAM even for large resultsets.

I have to admit I hadn't considered denial of service security issues.

Best regards,
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

More information about the mapserver-dev mailing list