On 4/29/2011 6:37 AM, Jan Hartmann wrote:
Thanks Steve. I don't understand the syntax: in the regex versions I
use,"." means"one and just one character", not any string. Any
string excluding the null-string would be".+" or"..*"
Not "." means match any single character in the string. It does not mean
match a string of just one character. Basically it means match any
string the is not a null string.
"." - match any character in a string the is not a null string
".*" - match any string the is 0 or more characters
"^.$" - match a string the is exactly one character long
"^$" - match only an empty/null string
".+" - match any string that is one of more characters
"..*" - match any character followed by 0 or more characters
More generally, I still have problems with validation as a concept:
it's too difficult, and perhaps that's why it isn't documented. I
The doc team has done a great job with the documentation, but there are
always areas for improvement and this is one of those areas that we need
to improve the documentation.
have postings about this subject in my personal mapserver-dev
mail-archive dating from 2002 (couldn't find them on the official
site any more), and there still isn't a clear solution almost ten
years later.
IMHO the major security risk of MapServer CGI is that it gives access
to the filesystem outside the web-root. Wouldn't it be better to keep
security at that level, i.e. only let MapServer access explicitly
defined parts of the filesystem? Within these parts, it's up to the
Definitely not, in my opinion, I do not want my valuable data files
which are sometimes licensed data in my document root tree where someone
can download them.
Also, mapserver does not have any idea of what the webserver's document
root is. In fact under Apache you can map any arbitrary directory into
the a serviceable directory by the webserver.
web-site builder to put only those things that should be visible and
nothing else. You don't put an ultra-secret document on the web and
afterward restrict access to portions only, you just put there what
you want to show to the world. Same goes for validations on extent or
styles: just make your selections of what you want to show"before"
you let MapServer loose on it.
Mapserver serves imagery that is rendered in a context, it does not
serve the underlining raw data files.
The same story can be told for database access and restrictions on
SQL queries: IMHO that is a matter for the database system. It's easy
enough to put everything behind barriers with user privileges and
views. Why should mapserver double all that security? Any competent
database administrator should know how to prevent SQL injects, and
MapServer should not be there to protect those who are unable to.
I've been working with Cloud VM's for about a year now, and in that
environment many security problems disappear: just make small,
dedicated servers and interconnect them, e.g. with cascading
services.
So my view would be: let the Operating System and the Database do
everything needed to secure files and databases, and put in your web
services only afterwards. It all gets too complex with all those
interconnected securities at all levels of the system (my main
problem with Apache).
In the last ressort: KISS (Keep It Simple Steve (whoever)) :-)
This all sounds great, but I don't have a Cloud, or all the services to
interconnect and cascade, and I'm not sure how I would set that up for
all the applications I have running. Maybe this needs some documentation
on how to do this better.
Regardless, mapserver has to support multiple environments. I do not
think it is reasonable to tell all mapserver users that they have to
re-architect there production environments because we do not want to
provide some basic tools to help with security if they are not building
systems like you are. If you know what you are doing then there is not
problem defeating the tools mapserver provides by effectively making
them a NOP.
As Steve L said, we can add a switch to turn it off if you want to
create a bug and we should do a better job on this documentation.
Personally, I would be interested in learning more about how you setup
and deal with the database, and filesystem issues and specifically how
to deal with SQL injection attacks in postgresql.
Thanks for your interesting and thoughtful use case.
-Steve W
Jan
-------------------------------------------------------------------------------------
On 04/28/11 18:48, Steve Woodbridge wrote
Hi Jan,
I do not think there is a global OFF switch for validation, but
where validation is required you can include the regex validation
string of /./ which means match anything except a null string, or to
also accept a null string then use /.*/
You still need to be aware of when you should put a validation in
place even if it accepts any string.
Regards, -Steve W
On 04/28/11 18:48, Jan Hartmann wrote:
I find the whole validation issue difficult and not well documented
(http://trac.osgeo.org/mapserver/ticket/3754, last updated four
hours ago). How do I put all validation off? I really don need that
much security.
Jan
On 04/28/11 18:19, Lime, Steve D (DNR) wrote:
I see the problem, just not sure how to fix it. Steve W. provided
some possibilities but that’s probably not the only approach. It
would be helpful if some interested person(s) got together and
drafted an RFC. I think the devs would be in a position to help
define implementation details if the problem is well defined
along with a proposed solution.
Steve
*From:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]] *On Behalf Of
*Rahkonen Jukka *Sent:* Thursday, April 28, 2011 4:21 AM *To:*
[email protected]
<mailto:[email protected]> *Subject:*
[mapserver-users] Validation beyond [A-z]
Hi,
Validation is nowadays needed in quite a many places in a
mapfile. However, we who live outside the English speaking world
tend to have more characters in the alphabet than A to Z. This
makes the mapfile validation idea only half effective because for
making things to work at all with the native data we must accept
almost everything that is non-numeric with wildcards. Are there
others who think that this is a problem?
Stephen Woodbidge commented slightly this topic in another thead
a month ago (Mar 29, 2011)
http://lists.osgeo.org/pipermail/mapserver-users/2011-March/068307.html
-Jukka Rahkonen-
_______________________________________________ mapserver-users
mailing list [email protected]
<mailto:[email protected]>
http://lists.osgeo.org/mailman/listinfo/mapserver-users
_______________________________________________ mapserver-users
mailing list [email protected]
<mailto:[email protected]>
http://lists.osgeo.org/mailman/listinfo/mapserver-users
_______________________________________________
mapserver-users mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapserver-users
