Title: frozen package import uses wrong files
Type: Stage:
Components: Interpreter Core Versions:
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: gvanrossum Nosy List: gvanrossum, htrd, jvr
Priority: low Keywords:

Created on 2001-02-27 10:18 by htrd, last changed 2002-11-24 20:35 by jvr. This issue is now closed.

File name Uploaded Description Edit htrd, 2001-02-27 10:18 zip of demonstration package
Messages (6)
msg3592 - (view) Author: Toby Dickenson (htrd) Date: 2001-02-27 10:18
In a frozen package, importing a module from 
another package causes the import machinery to try to 
open some curiously named files, before finally finding 
the frozen data.

It is possible to 'break' a frozen program by creating 
a file of that name. The frozen program will try to 
import from it rather than the frozen data.

The following collection of modules demonstrates this 
(also in the attached zip):

 Directory of D:\Projects\import

2001-02-27  08:57                   11
2001-02-27  08:49                   10
               2 File(s)             21 bytes

 Directory of D:\Projects\import\a

2001-02-27  08:57                   27
2001-02-27  09:58                    0
               2 File(s)             27 bytes

 Directory of D:\Projects\import\b

2001-02-27  08:56                   11
2001-02-27  09:58                    0
               2 File(s)             11 bytes

     Total Files Listed:
               6 File(s)             59 bytes
               0 Dir(s)   1,485,537,280 bytes free

The 'real' program is made up of the three files with 
single character names plus the two __init__ files. is a rogue file that breaks a frozen program. contains "import a.m"

a/ contains "import b.n". This is the import that 
goes wrong. When run as a normal script it imports 

However, a frozen binary appears to search for various 
a.b.* files over sys.path first. If it is run from the 
same directory as then it will load that file 
instead. Note that this file is not included in the 

msg3593 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-03-20 19:43
Logged In: YES 

I agree this is a bug.

I think there are lots of other ways to break frozen
programs, so I don't think this is a high priority security

I wish I had more time to research this, but I don't, so
I'll give this a low priority.  If someone submits a patch,
I'd be grateful!
msg3594 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-03-23 18:09
Logged In: YES 

Note, I tried this on Linux, and I couldn't reproduce it.  

What Python version were you using?
msg3595 - (view) Author: Toby Dickenson (htrd) Date: 2001-04-17 14:30
Logged In: YES 

Fix for this (and several other ways to break a frozen 
program) are in patch #416704 
msg3596 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-10-18 18:52
Logged In: YES 

This is now fixed by patch #416704 which is checked in.
msg3597 - (view) Author: Just van Rossum (jvr) * (Python triager) Date: 2002-11-24 20:35
Logged In: YES 

Almost two years later: I just tried this with Toby's patch
removed and can't reproduce this either (on OSX/Darwin).
Looking at find_module() in import.c I don't see how it
could *ever* be reproduced, since the frozen modules list is
always searched first.

The reason I bring this up again is that I currently have
the opposite problem: using extension modules as submodules
of frozen packages is not possible anymore. This goes both
for builtin extensions (dotted name in PyImport_Inittab
entry) as well as for dynamically loaded extension (dotted
name as .so/.pyd filename).

With MacPython we already encountered this problem earlier,
and Jack added an #ifdef macintosh switch, basically
disabling the patch. I'm going to suggest taking the switch
out and revert import.c to the old behavior. Will do so by
reopening patch #416704 unless another way is preferred.
Date User Action Args
2001-02-27 10:18:15htrdcreate