[Python-Dev] Capabilities

Paul Prescod paul@prescod.net
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")
print x.getfiles()
del x.__class__.__setattr__
x.foo = 5
del x.getfiles
del x.getdirs
x.getfiles()

Traceback (most recent call last):
   File "../foo.py", line 64, in ?
     x.getfiles()
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):
           ...
           def open2():
             print "open2"
             return open()



direct = DirectoryReader(".", "foo")
file = direct.getfiles()[0]
print file.open2()

FileReaderClass = file.__class__
del FileReaderClass.__setattr__

del file.open
print file.open2()

"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.

  Paul Prescod