I (Michael) wrote:
[Speaking of how to provide restricted execution in Python]
> Actually, I rather prefer the approach that has been mentioned before
> of trying to use capabilities.
> See, for instance, the threads on
> Capabilities found here:
> http://mail.python.org/pipermail/python-dev/2003-March/thread.html#33854
Luke replied:
> capabilities, acls, schmapabilities, same thiiing :)
No... they're not. Read the thread I mentioned above, or read this,
and some of the other documentation for the language E:
http://www.erights.org/elib/capability/ode/ode-capabilities.html
Later Luke writes:
> btw yes you're right, it's better off called "capabilities"
> but the name CCLs - capability control lists - is a bit of
> a mouthful :)
Again, I mean something different, NOT CCLs, but capabilities.
Hmm... how about a quick summary from me (but I'm not an expert).
Suppose that had some code which had an object representing a
directory, with a method "open(filename, mode='r')" that opened
files in the directory. Given this object, you could imagine
constructing new objects with more limited capabilities. For
instance, you might create a readOnlyDirectory object which had
a method "open(filename)" that didn't allow specifying the mode
as anything but 'r'. Or you might open a file and then pass a
file object with "read()", "write()", "seek()", and other such
methods, which would only access that file.
So _IF_ the only way to access files were through this object (and
that's a BIG if), then you could imagine a world where HAVING and
object was equivalent to being able to do something. If a bit of
code had access to a read-only-file object then it could read that
file, but couldn't write to it, or do anything else with the file
system unless it ALSO had access to some OTHER objects. That's
capabilities... and it would work for most kinds of restricted
resources, not just the file system. The key idea is that HAVING
a pointer to the object is equivalent to having the permission to
USE that object, and whatever it provides access to.
There are several ways to "escape" out of this system. One way is
to access some global ability... for instance, you might use the
"open()" function from __builtins__. For capabilities to work in
Python access to "dangerous" globals would need to be restricted.
Another way is to just create an object out of nowhere, or forge
a pointer to an object. Fortunately, in Python these are already
impossible... pure Python code cannot forge references or create
objects without access to the type or class. (C extensions can
do anything and are unsafe.)
Another way is to access the more powerful object that "empowers"
a less powerful one... perhaps using the (supposed to be private)
_directory field in the readOnlyfile object. So capabilities in
Python are impossible without some sort of private data for
objects (this is not a particularly onerous requirement). Yet
*another* approach would be to use introspection... for instance,
in Python today, given any file object, the class itself ("file")
can be obtained via introspection, and then used to create other
file objects. Using capabilities in Python would require that
"restricted" objects have some more limited form of introspection...
perhaps one could only obtain a "fake" class object which had
a __equals__ method that simulated being the real class, but
which had no __init__ so it couldn't be used to create new
instances.
At any rate, you get the idea. Capabilities are possible in Python
only if some sort of "restricted mode" is created, which restricts
access to some built-in abilities and which creates "restricted"
objects with some private data and limited introspection. But IF
you had these things (and they're NOT trivial), then capabilities
may be a conceptually more elegant approach than ACLs, lleading to
more elegant programs.
-- Michael Chermside
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