[UMN_MAPSERVER-USERS] mapserver 5 expression

[Jan Hartmann]

I didn't get any follow-up on this, so I am wondering what people think 
of it. If the reasoning is valid, and there are no other security issues 
with the expression statement, I would propose to return to version 4 
and make it possible again to access the expression-statement in 
MapServer CGI from the URL. That's really an important issue for me.

Thanks,

Jan

Jan Hartmann wrote:
> I don't mind rewriting my applications if the syntax is better, which it 
> probably is. I *do* mind giving up an essential MapServer functionality 
> for the CGI version. I don't know much about security, but I don't see 
> why you should build an extra security layer in the DATA statement for 
> expressions. The DATA statement is closed off, unless you set it open 
> via DATAPATTERN, and the SQL expressions (I guess that's where the pain 
> really is) can only get at that part of your database system that has 
> been opened by the CONNECTION parameter. If you let people connect to 
> your whole database with read and write rights, well I suppose you could 
> get into trouble then. But that is not necessary: you can create a user 
> within your database system with only those rights and accesses you 
> really want to expose, and specify that user in the CONNECTION line. No 
> one will be able to get past that user's rights. Am I missing something 
> here?
> 
> Jan
> 
> Steve Lime wrote:
>> You are correct. Even if we re-enabled that functionality applications
>> will
>> break because of the syntax change in how URL configuration is handled.
>> The migration guide talks about these changes.
>>
>> I agree that EXPRESSIONs are not as likely to suffer from security
>> problems
>> although I don't like the idea of allowing it since there is no way to
>> validate
>> an expression without evaluating it. No security problems with that
>> functionality
>> have been reported. I still prefer using the runtime subs where you can
>> apply
>> your own checks. You can substitute entire expressions that way too.
>>
>> Cc'ing mapserver-dev
>>
>> Steve
>>
>>>>> Jan Hartmann <j.l.h.hartmann at uva.nl> 08/31/07 7:31 AM >>>
>> Am I right that expressions could be changed by URLS in version 4 and 
>> cannot be changed any more in version 5? In that case I would strongly 
>> propose to reintroduce that possibility. It would break many of my 
>> applications, and I would need to use MapScript for those. Generally I 
>> only use CGI, because not all webservers I have to write for support 
>> MapScript. It's really a big restriction on MapServer CGI
>>
>> If there are security problems, I would like to see examples of those. 
>> Perhaps  more specific solution can be found then. Anayway, the DATA 
>> statement is protected by the DATAPATTERN statement in the mapfile, so 
>> if someone sets that open, he takes a risk anayway. Prohibiting 
>> changes to expressions in that situation is overkill IMO.
>>
>> Jan
>>
>> Steve Lime wrote:
>>> Expressions are not changable via URL configuration, at least not in
>>> their entirety like
>>> you are doing. I took a conservative approach to exposing parameters
>> to
>>> URL when
>>> that support was re-written for 5.0. I was concerned that unchecked
>>> manipulation of
>>> expressions and filters *could* be a security problem, so that is
>>> unavailable.
>>>
>>> What do folks think?
>>>
>>> Note that it is easy to re-enable. Just change line 162 in maplexer.l:
>>>
>>> from <INITIAL>expression ...
>>> to <INITIAL,URL_STRING>expression ...
>>>
>>> You can also work around this using runtime substitution. Presumably
>>> you'd write the mapfile
>>> entry like so:
>>>
>>>   LAYER
>>>     NAME 'fastvisa'
>>>     ...
>>>     CLASS
>>>         EXPRESSION ([FNR]=%myid%)
>>>     END
>>>   END
>>>
>>> and would have a URL like ...&myid=210176493&...
>>>
>>> The advantage here is the you make the decision to enable that level
>> of
>>> configuration, plus you
>>> can apply a regex filter to the value passed in from the URL and if
>> the
>>> value doesn't match that
>>> pattern then no substitution is made:
>>>
>>>   LAYER
>>>     NAME 'fastvisa'
>>>     ...
>>>     METADATA
>>>        myid_validation_pattern   '^\d{9}$'
>>>     END
>>>     CLASS
>>>         EXPRESSION ([FNR]=%myid%)
>>>     END
>>>   END
>>>
>>> In this example the input value for myid must consist of exactly 9
>>> digits.
>>>
>>> Steve
>>>
>>>>>> On 8/29/2007 at 7:28 AM, in message
>>> <BAY116-F20CE60F662031E0BD05A8182CC0 at phx.gbl>, Lars-Göran Edholm
>>> <lged_morris at HOTMAIL.COM> wrote:
>>>> Hi again!
>>>> Tried with
>>>> &map.layer[fastvisa].class[0]=EXPRESSION+([FNR]=210176493)
>>>> gives the error:
>>>> loadClass(): Unknown identifier. Parsing error near
>>> (EXPRESSION):(line 1)
>>>> with
>>>> &map.layer[fastvisa].class[0].EXPRESSION=([FNR]=210176493)
>>>> i get
>>>> loadClass(): Unknown identifier. Parsing error near (():(line 1)
>>>>
>>>> Seems that there is something with Expression that is wrong.
>>>> Lars-Göran Edholm
>>>>
>>>> _________________________________________________________________
>>>> Upptäck kärleken på MSN 
>>>> http://match.se.msn.com/channel/index.aspx?trackingid=1002962
>>
>