[Python-Dev] Re: Capabilities (we already got one) (original) (raw)

Michael Chermside mcherm@mcherm.com
Thu, 3 Apr 2003 05:09:31 -0800

The objection to doing it the other way round is that for capability languages to be truly usable the capability functionality needs to be automatic, not something that is painfully added to each class or object (at least, that is the claim we capability mavens are making).

Just how strong a claim are you making here?

It seems to me that the need for security (via capabilities or any other mechanism) is an UNUSUAL need. Most programs don't need it at all, others need it in only a few places. Now don't get me wrong... when you DO need it, you really need it, and just throwing something together without explicit language support is somewhere between impossible and terrifically-difficult-and-error-prone. So supporting secure execution (via capabilities or whatever) in the language is a great idea. And I like the capabilities-as-references approach... it's simple, elegant, and not error prone.

But if you're going so far as to imply that capability functionality needs to be present ALWAYS, and supported (and considered) in every class or object, then that's going too far. A random module should, for instance, be able to open arbitrary files in the file system without being passed any special objects, UNLESS we do something special when we load it to indicate that we want it to run in a restricted mode.

I think that zipfile is a good example here. As a library developer, I should be able to write and distribute a zipfile module without thinking about capabilities or security at all. Of course, when others go to use it in a secure or restricted mode, they may find that it isn't as useful as they'd like, but (I believe) we shouldn't say NO ONE can have a zipfile module unless the module author is willing to address security issues. Someone can write securezipfile when they get the itch.

Now, if we really built security (via capabilities) into the language from the ground up, then ALL modules would work by being passed appropriate capability objects, and only the starting script would possess all capabilities. There would be no "file" builtin, just file objects (and ReadOnlyFile objects, and DirectorySubTree objects, and so forth) which got passed around. So OF COURSE the original author of zipfile would write it to accept a file at construction rather than allowing it to open files... that would be the natural way to do things. But that language isn't python... and I don't think it's worth changing Python enough to get there.

So if you're proposing this drastic a change (which I doubt), then I think it's too drastic. But if you're NOT, then you have to realize that there will be lots of library modules like zipfile, which were written by people who didn't give any thought to security (since it's a rarely-used feature of the language). So we need workarounds (like wrappers or proxies) that can be applied after-the-fact to modules and classes that weren't written with security in mind. If that's "painfully adding something to each class or object", then I don't see how it's to be avoided.

-- Michael Chermside