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

[Ben Laurie]

Michael Chermside wrote:
>>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.

I am completely in agreement. Taming of existing modules is inevitably 
going to be somewhat painful - and, in some cases, it may be less 
painful to simply rewrite them. As you suspect, what I am proposing is 
that _when_ a programmer wishes to use capabilities as a security 
mechanism, it is desirable to make that as easy to use as possible.

I'm not sure I agree that the need for security is particularly unusual 
but I don't think its worth having a big argument about. I certainly do 
agree that crippling Python in order to get capabilities is not a 
desirable outcome. Not that I have that option anyway :-)

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff