<div dir="ltr">Patches welcomed! The config files do normalize site-level configuration like this but yes, regexes can be daunting - although they are an important part of configuration in a variety of ways, I don't know that we can simplify things too much. My preferred approach is to use mapfile aliases exclusively and get away from path filtering altogether.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 10, 2022 at 2:18 PM Jeff McKenna <<a href="mailto:jmckenna@gatewaygeomatics.com">jmckenna@gatewaygeomatics.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I suppose that is another performance hit.  So cancel that one, ha.<br>
<br>
Anyway, I do think it's good to discuss the issues, even if nothing else <br>
can be done.<br>
<br>
I'll continue to tackle this on the packaging side.<br>
<br>
-jeff<br>
<br>
<br>
<br>
On 2022-02-10 4:09 p.m., Jeff McKenna wrote:<br>
> For example (me thinking out of the box), could the MapServer config <br>
> file contain a section where users can specify paths or characters to <br>
> disallow (not a regular expression), and then MapServer would convert <br>
> that to a regular expression (in either PCRE or libregex syntax) and <br>
> apply it at run-time.<br>
> <br>
> -jeff<br>
> <br>
> <br>
> <br>
> On 2022-02-10 4:00 p.m., Jeff McKenna wrote:<br>
>> The tricky part here is that most recent packages use the PCRE regular <br>
>> expression library, because of its open BSD license, but the "bad" <br>
>> pattern hardcoded into the MapServer source is for libregex, which is <br>
>> GPL based, and that expression won't work with the PCRE engine.<br>
>><br>
>> My thoughts were when the idea of a "MapServer config file" coming, <br>
>> was that phew, then users can just point to their valid mapfiles there <br>
>> with simple paths or even wildcard paths or directories, and we can <br>
>> completely remove that bad pattern stuff from the source code.<br>
>><br>
>> So I assumed that the new config file would save us.  In fact the <br>
>> config file is just another place to put the bad pattern, which, <br>
>> honestly most MapServer users will never understand nor have the time <br>
>> to understand.<br>
>><br>
>> I am wondering, when we re-look at the bad pattern stuff, if we can <br>
>> think of a way that the new config file can replace the hardcoding <br>
>> inside the MapServer source.<br>
>><br>
>> I hope it's ok to wonder here out loud, ha.<br>
>><br>
>> -jeff<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On 2022-02-10 3:05 p.m., Tamas Szekeres wrote:<br>
>>> Steve,<br>
>>><br>
>>> I think we cannot avoid to be platform dependent in this regard. A <br>
>>> single slash at the beginning on Windows systems should not be <br>
>>> accepted, because it can specify a relative path, however a double <br>
>>> back slash at the beginning is accepted (absolute path of a network <br>
>>> share). Currently the single slash at the beginning is accepted in <br>
>>> all platforms.<br>
>>> Applying environment variables might not be a trivial task in all run <br>
>>> time environments, so I think the default behavior should work in <br>
>>> that way which can do the right thing in most use cases.<br>
>>><br>
>>> Best regards,<br>
>>><br>
>>> Tamas<br>
>>><br>
>>><br>
>>> Steve Lime <<a href="mailto:sdlime@gmail.com" target="_blank">sdlime@gmail.com</a> <mailto:<a href="mailto:sdlime@gmail.com" target="_blank">sdlime@gmail.com</a>>> ezt írta <br>
>>> (időpont: 2022. febr. 10., Cs, 15:48):<br>
>>><br>
>>>     The idea was to limit things to local paths with no back references<br>
>>>     by default. We're not distinguishing between OSes in setting that<br>
>>>     pattern. It's possible it's a bit overzealous so we could tweak the<br>
>>>     default if that makes sense across operating systems. It can be<br>
>>>     overridden by environment variable (or within the config file) and<br>
>>>     could be turned off completely with an expression that will never <br>
>>> match.<br>
>>><br>
>>>     On Thu, Feb 10, 2022 at 4:34 AM Tamas Szekeres <<a href="mailto:szekerest@gmail.com" target="_blank">szekerest@gmail.com</a><br>
>>>     <mailto:<a href="mailto:szekerest@gmail.com" target="_blank">szekerest@gmail.com</a>>> wrote:<br>
>>><br>
>>>         Hi Developers,<br>
>>><br>
>>>         I noticed that the double back slashes are excluded from the<br>
>>>         accepted mapfile pattern in one of the commits not too long ago<br>
>>>         according to security vulnerability reasons. The bad patten<br>
>>>         regex is now looking like:<br>
>>><br>
>>>         const char *ms_map_bad_pattern_default =<br>
>>>         "[/\\]{2}|[/\\]?\\.+[/\\]|,";<br>
>>><br>
>>>         Do we have a specific reason why we don't accept the double back<br>
>>>         slashes at the beginning of the mapfile path? This normally<br>
>>>         refers to a network share which is considered to be an absolute<br>
>>>         path, and our use cases are working like that extensively. I<br>
>>>         guess we wanted to exclude the relative paths basically, but it<br>
>>>         seems not to be that case.<br>
>>>         I'm also wondering if the double forward slashes at the<br>
>>>         beginning makes much sense to exclude, since I think that is<br>
>>>         treated as a single forward slash in the unix like systems which<br>
>>>         is normally accepted.<br>
>>><br>
>>>         Thanks,<br>
>>><br>
>>>         Tamas<br>
>>><br>
>>>         _______________________________________________<br>
>>>         MapServer-dev mailing list<br>
>>>         <a href="mailto:MapServer-dev@lists.osgeo.org" target="_blank">MapServer-dev@lists.osgeo.org</a> <br>
>>> <mailto:<a href="mailto:MapServer-dev@lists.osgeo.org" target="_blank">MapServer-dev@lists.osgeo.org</a>><br>
>>>         <a href="https://lists.osgeo.org/mailman/listinfo/mapserver-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapserver-dev</a><br>
>>>         <<a href="https://lists.osgeo.org/mailman/listinfo/mapserver-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapserver-dev</a>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> MapServer-dev mailing list<br>
>>> <a href="mailto:MapServer-dev@lists.osgeo.org" target="_blank">MapServer-dev@lists.osgeo.org</a><br>
>>> <a href="https://lists.osgeo.org/mailman/listinfo/mapserver-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapserver-dev</a><br>
>><br>
>><br>
> <br>
> <br>
<br>
<br>
-- <br>
Jeff McKenna<br>
GatewayGeo: Developers of MS4W, MapServer Consulting and Training<br>
co-founder of FOSS4G<br>
<a href="http://gatewaygeo.com/" rel="noreferrer" target="_blank">http://gatewaygeo.com/</a><br>
_______________________________________________<br>
MapServer-dev mailing list<br>
<a href="mailto:MapServer-dev@lists.osgeo.org" target="_blank">MapServer-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/mapserver-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapserver-dev</a><br>
</blockquote></div>