El 07/05/2010, a las 21:27, Oswaldo Hernández escribió:
> Reynaldo Baquerizo escribió:
>> En definitiva, ¿Qué es lo que quieres evitar? Hay cosas muy dañinas
>> que un usuario tontorrón puede hacer y que son muy difíciles de
>> detener ("while 1: pass")
>> algunas ideas puedes sacar de esta receta
>> http://code.activestate.com/recipes/496746-restricted-safe-eval/
>
> La he estado viendo y creo que puedo sacar cosas muy interesantes, el exec lo
> realiza en un thread para controlar el timeout, y me llama la atencion
> especialmente el uso que hace de los módulos 'inspect' y 'compiler' para
> analizar el codigo a ejecutar.
>
> Python no deja de sorprenderme :)
Lee los comentarios; verás que hay varias situaciones que no están
contempladas.
Mientras el entorno restringido no sea oficial, es decir, que está bien
integrado al intérprete y bendecido por GvR y amigos tendrás unos cuantos
agujeros y lo que es peor, una falsa sensación de seguridad.
En mi opinión, hay dos alternativas viables. Si tienes usuarios en los que no
puedes confiar ni pedir responsabilidades (por ejemplo, un sitio web) es mejor
pasar del scripting de aplicaciones. Si puedes confiar en ellos (sabes quiénes
son, el grupo es acotado, etc.) dales todo el poder y que tengan bien claro que
lo tienen. Excluyo la opción de incorporar un evaluador de expresiones o un
minilenguaje o un DSL porque, aunque es una solución perfectamente válida, no
es lo que preguntabas.
Dicho de otro modo, conmigo o van todos desarmados o portando armas de fuego.
En este último caso, yo me quedo a kilómetros de distancia. El arco y flecha da
muchos dolores de cabeza: pierdes un montón de tiempo enseñando a los usuarios
a usarlo, se quejan de que no les sirve para cazar rinocerontes y hagas lo
hagas terminas recibiendo una flecha en el culo.
_______________________________________________
Python-es mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/
