On Sun, 30 Mar 2003, Paul Prescod wrote:
It wouldn't have hurt for you to describe how the code achieves security by using lexical closure namespaces instead of dictionary-backed namespaces. ;)
Sorry. :) I assumed it would be clear.
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?
That immutability isn't required in order to prevent filesystem access. That immutability is only there to prevent multiple clients of the same DirectoryReader to use the DirectoryReader as a communication channel.
Sneaky. :) In restricted mode you wouldn't be able to do that.
I can't see in this model how to implement what C++ calls a "friend" class.
I haven't tried an example that requires that yet, but two classes could communicate through access to a shared object if they wanted to.
If this technique became widespread, Python's restrictions on assigning to lexically inherited variables would probably become annoying.
The Namespace offers a possible workaround. I didn't end up using it in my second code example because none of the objects have mutable state, but here's how you could do it:
def Counter(): self = Namespace() self.i = 0
def next(): self.i += 1 return self.i
It would be cool if you could suggest little "security challenges" to work through. Given specific scenarios requiring things like mutability or friend classes, i think trying to implement them in this style could be very instructive.