[mapserver-users] New limitations with mapserver 5 CGI

[Stephen Woodbridge]

Paul Ramsey wrote:
> I'd like to see backwards feature compatibility available, and I think
> the CGI override controller is one of the most powerful
> (under-appreciated) features of Mapserver.
> 
> Since the control of what is over-rideable is in the lexer though,
> we're sort of in a narrow box. We could do a compile-time option,
> which would allow us to default to strict but allow (relatively) easy
> conversion to flexible. That wouldn't really help our Windows brethren
> though, since they mostly rely on pre-compiled versions, and binary
> maintainers don't maintain lots of different builds.
> 
> Having a map-level run-time directive to control the availability of
> URL over-rides would be the ideal, IMO.  Default, NONE.  Other
> options, STRICT and FULL.  However, I don't see how to get there from
> here with the lexer requirement.

Paul,

I think you would just build it with the lexer support always enabled 
but have the runtime restrict access to the feature based on the 
NONE|STRICT|FULL control flag.

-Steve W


> P.
> 
> On Thu, Jul 10, 2008 at 6:05 PM, Graeme Watmuff
> <gwatmuff at geographicweb.com.au> wrote:
>> Hi Steve,
>>
>> Thanks for replying and thanks for the coding pointers. You are right
>> about the mapserv 4.10 tileindex syntax. Like filter, it is simply
>> ignored by v5 rather than throwing an error. My apologies.
>>
>> Would it make sense to create a 'secure' version for the paranoid and a
>> another version with full functionality? I realize this would create
>> more maintenance work for you, but not all mapserver users are going to
>> be able to climb inside the code themselves to modify functionality
>> (fortunately we can).
>>
>> Regarding security, I presume you are concerned about mapserver exposing
>> sensitive data to unintended users. If so, should you be taking that
>> responsibility on yourself by limiting mapserver or should the onus be
>> upon mapserver users to manage their own data more responsibly? I am a
>> great believer in personal responsibility. If the security risk is made
>> clear to users, they can make their own decisions as to the data they
>> potentially expose to the world.
>>
>> We have greatly appreciated and benefited from the tremendous work you
>> and your associates have done in bringing mapserver to the world and we
>> have always looked forward to the added features of each new version.
>> But upgrading now comes at some degree of inconvenience for us and maybe
>> others unless someone wants to publish the workaround to resurrect lost
>> functionality for all to simply acquire.
>>
>> I am not convinced that limiting the previous functionality is the right
>> direction for mapserver unless you fear say a litigious threat from
>> security breaches that people may bring upon themselves (hardly your
>> responsibility). Those with seriously sensitive data are not going to
>> want expose the CGI to all the world via a browser-sent URL anyway. I
>> would expect them to send URLs from say, a java web app embedded in a
>> secured tomcat container.
>>
>> Just my thoughts.
>>
>> Regards and best wishes
>>
>> Graeme
>>
>> On Thu, 2008-07-10 at 17:13 -0500, Steve Lime wrote:
>>> Hi Graeme: Comments inline... I definitely underestimated the impacts of those
>>> changes. Anyway...
>>>
>>>>>> On 7/9/2008 at 11:23 PM, in message
>>> <1215663787.2513.112.camel at bongolx.ringo.net>, Graeme Watmuff
>>> <gwatmuff at geographicweb.com.au> wrote:
>>>> It has become apparent through some frustrating moments of trial and
>>>> error that many of the mapfile variables that were changeable via URL
>>>> with mapserver 4.10.x CGI seem no longer changeable with v5.x or 5.2.x.
>>>> There is a hint from the docs that this is because of security concerns?
>>>> Our java apps don't allow web users to directly interact with the CGI,
>>>> so security doesn't seem so important in our case.
>>> Allowing unaltered, direct modification of things like FILTERs or CONNECTIONS
>>> is a potential security risk although I've never run across a documented case. Filters
>>> are risky because they are passed to the underlying data driver which generally
>>> trust the contents.
>>>
>>>> Some examples:
>>>>
>>>> map_web_metadata='text1' 'text2'
>>>> map_layerName_filter=<expression>
>>>> map_layerName_tileindex=<tileindex.shp>
>>>> map_layerName_data=<datasource>
>>>>
>>>> allow changes to the mapfile via URL with mapserver 4.10.x
>>>>
>>>> Following the new syntax specified for v5 + I had expected
>>>>
>>>> map_web=metadata+"'text1' 'text2'" or maybe
>>>> map_web_metadata[0]='text1'+'text2',
>>>> map_layer[layerName]=filter+<expression>,
>>>> map_layer[layerName]=tileindex+<tileindex.shp>,
>>>> map_layer[layerName]=data+<datasource>
>>>>
>>>> to all perform in the time-honoured way.
>>> And they don't... If they did you could combine modifications to a layer in a single
>>> variable:
>>>
>>>   map_layer[layerName]=filter+<expression>+tileindex+<tileindex.shp>+data+<datasource>
>>>
>>>> Only 'data' could be changed with this new mapserver 5 syntax. I
>>>> happened to discover through the change logs that changing tileindex was
>>>> reinstated for mapserver 5 CGI, but using the old mapserver 4.10 syntax
>>>> (map_layerName_tileindex)=<tileindex.shp> - not the new mapserver 5
>>>> syntax style (map_layer[layerName]=tileindex+<tileindex.shp>).
>>> Looking at the code, TILEINDEX is not changable via a URL with any syntax. The
>>> change log references a bug fix to 4.10. The old syntax doesn't work at all.
>>>
>>>> mapserv 5 CGI throws an error (Parsing error near (filter)) when the new
>>>> syntax is used for filter and ignores the old 4.10 filter syntax.
>>> This is expected. It will fail with an error as opposed to the silent failure of versions
>>> past.
>>>
>>>> No URL syntax for changing the web object's metadata content appears
>>>> acceptable to the mapserver 5.
>>> Correct.
>>>
>>>> I would dearly like to see changing the layer filter via URL restored
>>>> also to mapserver 5. And the web object's metadata setting functionality
>>>> too.
>>> It's possible to customize this behavior by editing maplexer.l and recompiling
>>> the code. Simply find the keyword you're interested in supporting and change
>>> the states at which it is valid. So, for TILEINDEX:
>>>
>>> <INITIAL>tileindex
>>>
>>> becomes:
>>>
>>> <INITIAL,URL_STRING>tileindex
>>>
>>> Same goes for the other parameters you'd want to activate.
>>>
>>>> Can anyone indicate what mapfile properties are or are not going to be
>>>> reinstated in mapserver 5 compared to mapserver 4 for change via URL?
>>>> Obviously this has development ramifications for us when we try to
>>>> upgrade mapserver.
>>> If I (or anyone) can think of a way to make this tunable at runtime I'd love
>>> to talk more about it. The set of parameters supported in 5.2 has only changed
>>> a little bit since 5.0 based on user input. I can't see exposing more without
>>> good reason. FILTER in particular is worrisome and there is a work around with
>>> the runtime substitution (e.g. FILTER %someval%). In that example you can
>>> pass someval via URL but you have to define a validation pattern (a regex) to
>>> check it against.
>>>
>>>> Alternatively, am I missing something with new mapserver 5 syntax?
>>> I'm curious if updating maplexer.l to fit your particular needs is workable.
>>>
>>>> Graeme Watmuff
>>> Steve
>>>
>> --
>> Graeme Watmuff
>> Geographic Web Solutions Pty Ltd
>> 17 Tay Road
>> Woodforde
>> South Australia  5072
>> ph:  + 61 8 83364463
>>
>> _______________________________________________
>> mapserver-users mailing list
>> mapserver-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>>
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users