<div dir="ltr">Hi Even,<div><br></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 12, 2016 at 2:31 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I wanted to mention a new (and I think pretty cool ) feature I've added in<br>
trunk: the possibility to define pixel functions in Python in a VRT derived<br>
band.<br>
<br>...<br>
<br>
There are obvious security concerns in allowing Python code to be run when<br>
getting the content of a vrt file. The GDAL_VRT_ENABLE_PYTHON config option =<br>
IF_SAFE / NO / YES can be set to control the behaviour. The default is IF_SAFE<br>
(can be change at compilation time by defining<br>
-DGDAL_VRT_ENABLE_PYTHON_<wbr>DEFAULT="NO" e.g. And Python code execution can be<br>
completely disabled with -DGDAL_VRT_DISABLE_PYTHON). Safe must be understood<br>
as: the code will not read, write, delete... files, spawn external code, do<br>
network activity, etc. Said otherwise, the code will only do "maths". But<br>
infinite looping is something definitely possible in the safe mode. The<br>
heuristics of the IF_SAFE mode is rather basic and I'd be grateful if people<br>
could point ways of breaking it. If any of the following strings - "import"<br>
(unless it is "import numpy" / "from numpy import ...", "import math" / "from<br>
math import ..." or "from numba import jit"), "eval", "compile", "open",<br>
"load", "file", "input", "save", "memmap", "DataSource", "genfromtxt",<br>
"getattr", "ctypeslib", "testing", "dump", "fromregex" - is found anywhere in<br>
the code, then the code is considered unsafe (there are interestingly a lot of<br>
methods in numpy to do file I/O. Hopefully I've captured them with the previous<br>
filters). Another 'unsafe' pattern is when the pixel function references an<br>
external module like my above my_lib.hillshade example (who knows if there<br>
will not be some day a shutil.reformat_your_hard_<wbr>drive function with the right<br>
prototype...)<br>
<br>
This new capability isn't yet documented in the VRT doc, although this message<br>
will be a start.<br>
<br>
I'm interested in feedback you may have.<br></blockquote><div><br></div><div>I found <a href="http://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html">http://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html</a> 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": <a href="https://lwn.net/Articles/574215/">https://lwn.net/Articles/574215/</a>. I'm not knowledgeable enough about sandboxing (OS or otherwise) to say if that's right.</div><div><br></div><div>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? My ignorance of how GDAL separates "open" options from "config" options might be on display in this question.<br></div><div><br></div></div><div><div>My $.02 is that since "is safe" will be hard to guarantee (it's an outstanding unsolved Python community issue), removing "IF_SAFE" from the options would be a good thing and that the default for GDAL_VRT_ENABLE_PYTHON should be "NO".</div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Sean Gillies</div></div>
</div></div>