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]> 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]> > 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] >> https://lists.osgeo.org/mailman/listinfo/mapserver-dev >> >
_______________________________________________ MapServer-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/mapserver-dev
