[pyar] [RFC] PyOpaque - soporte de atributos privados en python

david tenuki en gmail.com
Mie Jun 27 19:22:37 ART 2012


2012/6/27 Luciano Bello <lbello en gmail.com>

> On Wed, Jun 27, 2012 at 8:46 AM, david <tenuki en gmail.com> wrote:
>


> > Por eso.. lo que muestro ahí arriba, está bien, es un ejemplo trucho,
> > abusando quizás de como está armado el challenge.
>
> Bart sugirió agregar "then" en la definición del challenge. El mismo ahora
> es:
>
> You are callenged to run "python -i croupier.py" and *then* find a way
> to learn the content of the deck of Jack, the croupier.


Es que en realidad, está bien para la instancia de jack creada. Porque si
en algún momento se va a crear otro jack se puede hacer facil que use: un
nuevo random, una nueva shuffle... etc...




> > Una cosa que tiene python,
> > ni hace falta que lo diga en realidad, es que es todo muy abierto,
> entonces
> > genera muchos lugares por donde "acceder" a lo mismo. Ojo no critico que
> sea
> > muy abierto.. me gusta que sea así.
>
> Si. A mi también me gusta. Sin embargo es algo complicado de defender
> en el mundo académico. Un lenguaje es tan expresivo como cantidad de
> programas permite escribir. Sin embargo, hay programas que se pueden
> escribir en haskell (tipos estáticos, puaj :P) y no en Python, como
> por ejemplo, un mecanismo para enforce information flow [1]. Así que
> esto es lo que motivó el trabajo práctico... hacer python más
> expresivo, en algún sentido.
>
> [1] Este paper es un ejemplo de dicho mecanismo:
> http://www.cse.chalmers.se/%7Erusso/publications_files/haskell11-ext.pdf
> Nuestro trabajo práctico inicial era llevar las ideas de este paper a
> un lenguaje más dinámico.
>

Gracias por el link!



> > Y por eso mismo, creo, es muy interesante lo que hicieron uds. Después
> voy a
> > probar si con import hooks se puede hacer lo mismo que hago con random,
> sin
> > tener que copiarme el módulo random, que siempre se puede hacer pero en
> > algún caso puede ser trabajoso.
> > Y me gustaría entender que es lo que hace, de lo poco que ví en el
> código,
> > el tema de los safe-imports y la black list de los mismos. Está para no
> > permitir cosas como ctypes?
>
> Como comenté, el objetivo del modulo no es controlar el acceso a los
> imports (supone que de alguna forma ya está sandboxeado). La función
> disableDangerousImports intenta evitar que accedas a cosas como gc
> (simpático es el hecho que usa el mismo mecanismo que se usa para
> evitar el acceso a objetos que se quiere segurizar).


Acá otro "ataque":

aweil en patashnik:~/tmp/bvdelft-PyOpaque-fd29f6b/examples$ python -i
croupier.py
>>> import traceback
>>> import os
>>> sys = os.sys
>>> def mytracef(*args):
...     f = args[0]
...     try:
...             print f.f_locals['self'].deck
...     except:
...             pass
...
>>> sys.settrace(mytracef)
>>> jack.drawCard()
[31, 26, 36, 16, 10, 0, 11, 33, 3, 32, 15, 23, 49, 45, 51, 50, 12, 47, 13,
28, 1, 9, 7, 17, 48, 29, 40, 14, 24, 35, 38, 25, 41, 19, 6, 42, 44, 39, 20,
5, 27, 2, 37, 46, 18, 43, 34, 30, 8, 4, 21, 22]
22
>>> sys.settrace(None)
>>>

Antes de que drawCard() nos devuelva una carta, ya sabemos cual es todo el
mazo.


Usar gc hubiera estado re bueno para buscar entre todas las listas
instanciadas en el sistema cual parece y es un deck.. pero no la pude
conseguir. Por suerte con conseguir sys, alcanzó!

Saludos!
-- 
 There is no dark side of the moon really. Matter of fact it's all dark.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20120627/fe56a46b/attachment.html>


More information about the pyar mailing list