[Python-Dev] Capabilities

[Ka-Ping Yee]

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.

> del x.__class__.__setattr__

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

        return ImmutableNamespace(next)

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.


-- ?!ng