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

[Michael Chermside]

> 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