[gdal-dev] Filesystem & Network access in OGRSpatialReference.SetFromUserInput()
Robert Coup
robert.coup at koordinates.com
Tue Sep 27 04:32:53 PDT 2022
Hi all,
Currently SetFromUserInput() accepts all sorts of things as input for
a CRS definition — flavours of WKT, various EPSG/ESRI/etc identifiers
& combinations, OGC URNs/UR:s, Proj4 definitions, a set of static
names, and ProjJSON. As well, it accepts arbitrary http(s) urls & file
paths (including VSI paths), which may contain WKT/XML/PROJ4. (I
haven't looked whether the XML parser can then go on to load external
resources too)
This is certainly a useful function: a parser that accepts EPSG:1234,
compound CRSs (EPSG:1234+5678, and the same via URNs), WKT, and useful
names like "NAD27" is great.
While network & filesystem access can be disabled via the C++
interface, this isn't exposed to the C or SWIG bindings, and there's
no config override/defaults. GDAL does refuse to load large files, and
the results are then parsed as WKT/XML/etc so it's not trivial to
exploit, but nevertheless.
*Personally* I'd prefer an opt-in behaviour to any filesystem or
network access for functions which are pitched as swiss-army-knife
string parsers.
I understand there's backwards compatibility concerns at play, but
maybe some/all/any of:
1. Expose the ALLOW_NETWORK_ACCESS & ALLOW_FILESYSTEM_ACCESS
limitation options to SetFromUserInput() to the SWIG & C interfaces
2. Have a config option that sets the defaults for the limitations.
3. Swap the default limitations from allowing to denying at a future
release so users would need to opt-in.
4. Split out file/network access to separate functions.
Opinions & ideas most welcome.
Thanks,
Rob :)
More information about the gdal-dev
mailing list