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