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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4