On Sat, 9 Apr 2005, James Y Knight wrote:
> You can protect against this, too, but it does show that it's *really*
> hard to get restricting code right...
Good point. If you can't trust ==, then you're hosed.
> I'm of the opinion that it's not
> really worth it -- you should just use OS protecti
On Apr 9, 2005, at 5:37 PM, Ka-Ping Yee wrote:
Let me know if you figure out how to defeat that.
You can protect against this, too, but it does show that it's *really*
hard to get restricting code right...I'm of the opinion that it's not
really worth it -- you should just use OS protections.
unt
Ka-Ping Yee wrote:
On Sat, 9 Apr 2005, Jp Calderone wrote:
Does using the gc module to bypass this security count? If so:
[EMAIL PROTECTED]:~$ python -i facet.py
>>> import gc
>>> c = readonly_facet.__getattr__.func_closure[1]
>>> r = gc.get_referents(c)[0]
>>> r.n = 'hax0r3d'
>
On Sat, 9 Apr 2005, Michael Hudson wrote:
> The funniest I know is part of PyPy:
>
> def extract_cell_content(c):
> """Get the value contained in a CPython 'cell', as read through
> the func_closure of a function object."""
> # yuk! this is all I could come up with that works in Python
On Sat, 9 Apr 2005, Jp Calderone wrote:
> Does using the gc module to bypass this security count? If so:
>
> [EMAIL PROTECTED]:~$ python -i facet.py
> >>> import gc
> >>> c = readonly_facet.__getattr__.func_closure[1]
> >>> r = gc.get_referents(c)[0]
> >>> r.n = 'hax0r3d'
>
On Apr 9, 2005, at 2:13 PM, Michael Hudson wrote:
The funniest I know is part of PyPy:
def extract_cell_content(c):
"""Get the value contained in a CPython 'cell', as read through
the func_closure of a function object."""
# yuk! this is all I could come up with that works in Python 2.2
On Sat, 9 Apr 2005, Fredrik Lundh wrote:
> Ka-Ping wrote:
> > counter = Counter()
> > readonly_facet = facet(counter, ['value'])
> >
> > If i've done this correctly, it should be impossible to alter the
> > contents of the list or the counter, given only the immutable_facet
> > or the reado
On Apr 9, 2005, at 11:15 AM, Michael Hudson wrote:
"Gregory P. Smith" <[EMAIL PROTECTED]> writes:
Under "Limitations and Exclusions" it specifically disowns
responsibility for worrying about whether Py_Initialize() and
PyEval_InitThreads() have been called:
[snip quote]
This suggests that I should
"Gregory P. Smith" <[EMAIL PROTECTED]> writes:
>> > Under "Limitations and Exclusions" it specifically disowns
>> > responsibility for worrying about whether Py_Initialize() and
>> > PyEval_InitThreads() have been called:
>> >
>> [snip quote]
>>
>> This suggests that I should call PyEval_InitThre
Jp Calderone <[EMAIL PROTECTED]> writes:
> Does using the gc module to bypass this security count? If so:
>
> [EMAIL PROTECTED]:~$ python -i facet.py
> >>> import gc
> >>> c = readonly_facet.__getattr__.func_closure[1]
> >>> r = gc.get_referents(c)[0]
> >>> r.n = 'hax0r3d'
Ka-Ping wrote:
> counter = Counter()
> readonly_facet = facet(counter, ['value'])
>
> If i've done this correctly, it should be impossible to alter the
> contents of the list or the counter, given only the immutable_facet
> or the readonly_facet, after restrict() has been called.
I'm prob
> pickle doesn't have the INF=>1.0 bug:
>
import pickle
pickle.loads(pickle.dumps(1e1))
> ...
> ValueError: invalid literal for float(): 1.#INF
>
import cPickle
cPickle.loads(cPickle.dumps(1e1))
> ...
> ValueError: could not convert string to float
>
import marshal
Skip Montanaro wrote:
> Martin> Yet, this *still* is a platform dependence. Python makes no
> Martin> guarantee that 1e1000 is a supported float literal on any
> Martin> platform, and indeed, on your platform, 1e1000 is not supported
> Martin> on your platform.
>
> Are float("inf")
Skip Montanaro wrote:
> Are float("inf") and float("nan") supported everywhere?
nope.
>>> float("inf")
Traceback (most recent call last):
File "", line 1, in ?
ValueError: invalid literal for float(): inf
>>> float("nan")
Traceback (most recent call last):
File "", line 1, in ?
ValueError: i
Martin> Yet, this *still* is a platform dependence. Python makes no
Martin> guarantee that 1e1000 is a supported float literal on any
Martin> platform, and indeed, on your platform, 1e1000 is not supported
Martin> on your platform.
Are float("inf") and float("nan") supported every
Terry Reedy wrote:
> The particular issue here is not platform dependence as such but
> within-platform usage dependence, as in the same code giving radically
> different answers in a standard interactive console window and an idle
> window, or when you run it the first time (from xx.py) versus
On Sat, 9 Apr 2005 00:13:40 -0500 (CDT), Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>On Fri, 8 Apr 2005, Eyal Lotem wrote:
> > I would like to experiment with security based on Python references as
> > security capabilities.
>
> This is an interesting and worthwhile thought. Several people
> (includi
17 matches
Mail list logo
