PEP 304 - Controlling generation of bytecode files
skip at pobox.com
Wed Jan 29 20:18:51 CET 2003
Laura> 1. I the the name PYTHONBYTECODEDIR and sys.bytecodedir (that is
Laura> plenty enough to type already) make more sense.
The environment variable's first incarnation had "DIR" in the name.
This can be a bit misleading though. A couple folks on python-dev thought I
was proposing dumping all .pyc files directly into that directory.
"...BASE" sort of suggests to me that it's the head of a tree. I shortened
the sys variable to "bytecodebase".
Laura> 2. This Pep assumes that you want to change files globally, but
Laura> not on a per file basis. What do we want to happen when 2
Laura> users of the same system -- a) want different dirs, b) want
Laura> the same dir. In case b) can we still get collisions and a
Laura> corrupted file?
As I mentioned in an earlier reply, this is not intended to allow
module-by-module (or even directory-by-directory) control of .pyc file
Laura> 3. I am unclear of the security implications of this. Is
Laura> somebody out there depending on the fact that nobody can ever
Laura> write their own bytecode files and use them to crack the
Laura> system? If so they are likely to want a way to forbid any but
Laura> their system secure ones.
Security is really no different than in the current system. If you and I
can write to the same directory, then you can do something to my .pyc files
to corrupt them. In the PEP I have these issues:
- Security - What if root has PYTHONBYTECODEBASE set? Yes, this can
present a security risk, but so can many other things the root user
does. The root user should probably not set PYTHONBYTECODEBASE except
during installation. Still, perhaps this problem can be minimized.
When running as root the interpreter should check to see if
PYTHONBYTECODEBASE refers to a directory which is writable by anyone
other than root. If so, it could raise an exception or warning and
set sys.bytecodebase to None. Or, see the next item.
- More security - What if PYTHONBYTECODEBASE refers to a general
directory (say, /tmp)? In this case, perhaps loading of a preexisting
bytecode file should occur only if the file is owned by the current
user or root. (Does this matter on Windows?)
I think the second issue may address your concerns. In any case, even if
the PEP is not accepted, the second item might be a worthwhile enhancement
Laura> 4. One thing that I would find useful is a way to say "do not
Laura> make pyc's in this dir". Then when I tar up a distribution to
Laura> send someplace I won't have to remember to remove them first.
I don't think that's within the scope of this PEP. When creating a tarfile
distribution why not just give an excludes argument to (at least GNU) tar
telling it to exclude .pyc files?
More information about the Python-list