[Python-Dev] new security doc using object-capabilities (original) (raw)

Brett Cannon brett at python.org
Thu Jul 20 19:09:07 CEST 2006

On 7/20/06, Nick Coghlan <ncoghlan at gmail.com> wrote:

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

Right, but some people like to construct directly from bytecode.

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.

I figured as much, but when I was making the list I was not sure and didn't want to stop my writing momentum to check.

For rewriting import.c in Python, the PEP 302 compliant import system API in

pkgutil would be a good starting point.

Yep. Plan on looking at all of the various modules in the stdlib that assist with importing, package PEP (I think there is one), and PEP 302.

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. getsuffixes() is built from PyImportFileTab, which is a C array. A switch statement is used to get from the file table entries to the appropriate handler functions.

Ah, OK.

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 PyImportFileTab, 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.

Yep. I just kind of glanced at the rest of your suggestions, Nick, since I assumed a lot of it would change (or could be changed) if import was redone in as much Python as possible.

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.

Yep. Although I am more interested in restricting than broadening the file types.

This could be handled on a per-package basis, e.g. via a file_types

special attribute in packages.

Maybe. I don't want to get into introducing new abilities to start, though.

-Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060720/32151d26/attachment-0001.htm

More information about the Python-Dev mailing list