[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