[Python-Dev] new security doc using object-capabilities

[Nick Coghlan]

For code objects, their construction is already commonly written as 
"compile(source)".

For type objects, the constructor doesn't let you do anything you can't 
already do with a class statement. It doesn't need securing.

For rewriting import.c in Python, the PEP 302 compliant import system API in 
pkgutil would be a good starting point.

Your doc also asks about the imp.get_suffixes() list, and wonder where to set 
it from Python.

As far as I am aware, you can't. get_suffixes() is built from 
_PyImport_FileTab, which is a C array. A switch statement is used to get from 
the file table entries to the appropriate handler functions.

Quoting from the suggestions I put to the Py3k list:

Use smarter data structures
---------------------------
Currently, the individual handlers to load a fully identified module are
exposed to Python code in a way that reflects the C-style data structures used
in the current implementation.

Simply switching to more powerful data structures for the file type handlers
(i.e. use a PyTuple for filedescr values, a PyList for _PyImport_FileTab, and
a PyDict instead of a switch statement to go from filedescr values to module
loading/initialisation functions) and manipulating them all as normal Python
objects could make the code in import.c much easier to follow.

Extensible file type handling
-----------------------------
If the file type handlers are stored in normal Python data structures as
described above, it becomes feasible to make the import system extensible to
different file types as well as to different file locations.

This could be handled on a per-package basis, e.g. via a __file_types__
special attribute in packages.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org