[gdal-dev] Filesystem & Network access in OGRSpatialReference.SetFromUserInput()

[Even Rouault]

Robert,

Options 1, 2 and 3 sound reasonable to me.

For 3, you'd probably want to emit a deprecation warning during the 
transition period if the user relies on the functionality without having 
explicitly enabled it

For 4, the import from network exists as a separate function 
importFromUrl(), and that one is pretty much used for 
spatialreference.org (for the better or the worse given 
spatialreference.org not being updated since ages, but some MODIS 
products reference it...). There's no separate function for import from 
file (not sure how much this capability is used. gdalsrsinfo is one of 
the legitimate user of it I could think of)

 > I haven't looked whether the XML parser can then go on to load 
external resources too

This is our very simple cplminixml.cpp parser. It cannot load external 
resources.

Even

Le 27/09/2022 à 13:32, Robert Coup a écrit :
> 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 :)
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.