Sun, 30 Mar 2003 10:43:12 -0800
Ka-Ping Yee wrote:
> Specifically, the only introspective attributes we have to disallow, in
> order for these objects to enforce their intended restrictions, are
> im_self and func_globals. Of course, we still have to hide __import__ and
> sys.modules if we want to prevent code from obtaining access to the
> filesystem in other ways.
It wouldn't have hurt for you to describe how the code achieves security
by using lexical closure namespaces instead of dictionary-backed
namespaces. ;) Part of the trick is that the external names are
irrelevant to the functioning of the object.
I don't understand one thing.
The immutability imposed by the "ImmutableNamespace" trick is easy to
turn off. But once I turn it off, I couldn't figure out any way to
violate the security because the closure's variables are invisible to
any code that is not defined within its block. Why bother with the
ImmutableNamespace bit at all?
x = DirectoryReader(".", "foo")
x.foo = 5
Traceback (most recent call last):
File "../foo.py", line 64, in ?
AttributeError: ImmutableNamespace instance has no attribute 'getfiles'
But I couldn't figure out how to use this to get access to the file
system because as I said before, the external names are irrelevant to
the object's implementation. They are early bound.
def FileReader(path, name):
direct = DirectoryReader(".", "foo")
file = direct.getfiles()
FileReaderClass = file.__class__
"open2" binds to open at definition time, not at runtime. I can't see in
this model how to implement what C++ calls a "friend" class. Even C++
and Java have ways that related classes can poke around each others
internals. So perhaps this is part of what would need to change in
Python to have a first-class capabilities feature.
If this technique became widespread, Python's restrictions on assigning
to lexically inherited variables would probably become annoying.