[mapserver-users] New limitations with mapserver 5 CGI

[Steve Lime]

Graeme: Did you look at my last reply in the thread? I outlined a possible
solution that I would be willing to implement for 5.2.1/5.4 if ok with the
PSC. Does that seem workable for you?

Steve

>>> On 7/10/2008 at 7:22 PM, in message
<1215735745.2481.71.camel at bongolx.ringo.net>, 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+<datasou
> rce>
>> 
>> > 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
>>