[UMN_MAPSERVER-USERS] mapserver 5 expression

Jan Hartmann j.l.h.hartmann at UVA.NL
Sat Sep 8 07:50:25 EDT 2007 

Still no reaction. Folks, I really find this important: if EXPRESSIONS 
are not accessible any more from the URL in MapServer CGI, I have to 
switch completely to MapScript. I would hate to do  that, not so much 
for the programming trouble, but because the applications won't be 
portable any more to webservers without MapScript. This would mean that 
it will be impossible to do jobs for organisations with webservers that 
only allow CGI scripts. Many commercial providers don't allow more, and 
for government over here, you are lucky if they allow CGI scripts in any 
case. Installing MapScript in such an environment is simply out of the 
question.

My argument is that security problems with SQL-statements in the 
EXPRESSION can be solved by specifying a restricted user in the 
CONNECTION line. If there are other security reasons for protecting the 
EXPRESSION, please let me know, and I'll start converting my 
applications for release 5, and perhaps look out for a way of holding on 
to 4. If not, please consider opening up again the EXPRESSION statement.

Jan

Jan Hartmann wrote:
> 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
>>>
>>
>

More information about the mapserver-dev mailing list