[Python-Dev] capability-mediated modules (was: python-dev Summary for 2003-03-01 through 2003-03-15)

[Zooko]

 Greg Ewing <greg@cosc.canterbury.ac.nz> 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 
syntax):

# Python with E's parameterized import
import socket
import spam(socket.socket(socket.AF_INET, socket.SOCK_STREAM))

If spam needs access to the eggs module, you could write:

import eggs
import spam(eggs)


But as Samuele Pedroni has pointed out [1] 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()
ttt1.verify_card_number(mycreditcard)

ttt2 = TicTacToe()
ttt2.connect_to_server(socket.socket(socket.AF_INET, socket.SOCK_STREAM))


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.


Regards,

Zooko

http://zooko.com/
         ^-- under re-construction: some new stuff, some broken links

[1] http://mail.python.org/pipermail/python-dev/2003-March/034172.html