[Python-Dev] capability-mediated modules (was: python-dev Summary for 2003-03-01 through 2003-03-15)
Thu, 20 Mar 2003 16:34:00 -0500
Greg Ewing <firstname.lastname@example.org> wrote:
> Maybe, instead of there being one ultra-global namespace for importing
> modules from, it should be part of a function's environment. By
> default a function invocation would inherit the "import environment"
> of it's caller, but the caller could override this to provide a more
> restricted environment.
This is a reasonable idea too.
It bears an intriguing similarity to scoping in general. One can put
capabilities into local variables, and then functions and classes that you
define inside that scope automatically have access to them. That doesn't work
for separate modules, of course, which have no enclosing lexical scope.
So your proposal seems sort of like a kind of dynamic scoping for modules, but
instead of the imported module having access to all variables in the scope of
the "import" statement (the *lexical* scope of the import statement), it has
access to specific ones -- either a special "variables accessible to imported
modules" dict or specially flagged ones, or something.
For what it's worth, the solution to this problem in E is quite elegant. When
code is loaded from a module, it is executed with optional arguments. So if
your spam module requires a TCP socket, you can write (transliterating to Python
# Python with E's parameterized import
import spam(socket.socket(socket.AF_INET, socket.SOCK_STREAM))
If spam needs access to the eggs module, you could write:
But as Samuele Pedroni has pointed out  there are deeper problems here,
namely that modules are currently singletons, which doesn't fit with the notion
of parameterization. It also doesn't fit with security!
Consider a module that is safe to use if you give it your credit card number,
and safe to use if you give it a network socket, but unsafe if you give it both!
Capabilities offer this kind of security -- you can arrange it so that nobody
else can give privileges to an object, thus allowing you to give the object
privileges which would otherwise be dangerous.
This is easy with objects in cap-Python, but not with modules:
ttt1 = TicTacToe()
ttt2 = TicTacToe()
So one design for cap-Python might say that only safe modules can be imported by
cap-Python code. Every unsafe privilege would have to be granted by using
references (passed as arguments, assigned to variables, etc.). No authority
would ever be made available to capability-secured code through "import".
This might not be much of a loss, since all of the unsafe stuff that you can
currently import -- socket, os, etc. -- is rather too coarse-grained anyway and
will almost certainly be wrapped in a finer-grained interface before being given
to capability-confined code.
^-- under re-construction: some new stuff, some broken links