[gdal-dev] VRT derived band pixel functions written in Python

Even Rouault even.rouault at spatialys.com
Mon Sep 12 11:25:46 PDT 2016


> I found http://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html
> to be a good intro to the risks of eval'ing untrusted Python code.
> Mentioned in there is a notable attempt to make a secure subset of Python
> called "pysandbox", but its developer has since declared it "broken by
> design": https://lwn.net/Articles/574215/. I'm not knowledgeable enough
> about sandboxing (OS or otherwise) to say if that's right.

Those links are fascinating. I wouldn't have imagined that there was valid 
Python code that could crash the Python interpreter, almost by design ! (so 
the osgeo.gdal gotchas are not so bad after all :-) )
OK, so I've followed your suggestion:
* IF_SAFE mode is removed (actually between #if 0 / #endif if someone wants to 
pursue the sandboxing effort),
* and the default of GDAL_VRT_ENABLE_PYTHON is now NO.

> 
> I see that in GDAL 2.0+ we can set options in the VRT XML itself. Is it
> possible to set GDAL_VRT_ENABLE_PYTHON=YES in a VRT and thus override the
> reader's own trust policies?

No, that's not possible. GDAL_VRT_ENABLE_PYTHON is a config option only, so can 
only be set as a env variable or through CPLSetConfigOption().

We could imagine to provide it as an option of the VRT indeed, but then there 
would be interesting situations like the following. Imagine something called 
"my.tif" with the following content :

<VRTDataset rasterXSize="20" rasterYSize="20">
  <VRTRasterBand dataType="Byte" band="1">
    <ColorInterp>Gray</ColorInterp>
    <SimpleSource>
      <SourceFilename relativeToVRT="1"><![CDATA[
<VRTDataset .... evil Python code here ... .... >]]></SourceFilename>
      <OpenOptions>
        <OOI key="ENABLE_PYTHON">YES</OOI>
      </OpenOptions>
    </SimpleSource>
  </VRTRasterBand>
</VRTDataset>

The internalized VRT would then be allowed with ENABLE_PYTHON=YES.

So it's probably a good idea to not provide an open option for now. One could 
perhaps imagine to introduce one, provided we make it illegal as an item in 
<OpenOptions>, so it can only be provided by "top-level" GDALOpenEx() calls.

> My ignorance of how GDAL separates "open"
> options from "config" options might be on display in this question.

They are just 2 different mechanisms of providing options. There's no automatic 
bridge between both concepts. Sometimes some option may exist in both worlds 
(because historically there was only global config option, but in some use 
cases, some options mostly make sense per dataset) or in just one of them.

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list