[Python-Dev] PEP: per user site-packages directory (original) (raw)

Christian Heimes lists at cheimes.de
Sun Jan 13 10:45:04 CET 2008

Gregory P. Smith wrote:

My main suggestion was going to be the ability to turn it off as you already mentioned. However, please consider leaving it off by default to avoid problems for installed python scripts importing user supplied code. For shared hosting environments where this becomes really useful users can easily add the -s (or whatever flag is chosen) to their programs themselves. I don't know what that'd mean on windows where #! lines don't exist. Yet another file extension to imply the flag (yuck)? A .cmd wrapper script to run python with the flag (ugh)?

So you prefer to make the per use site-package directory an opt-in option? I prefer it as an opt-out option. It's enabled by default, unless the user disables the feature with -s.

I'm not sure how to solve the problem on Windows. IMHO the feature should be enabled on Windows at least but I like to keep it enabled on all systems. The PEP doesn't add a new attack vector. The problem also exist with PYTHONPATH. Paranoid programs should start with -E -s anyway and paranoid system administrators can switch a flag in site.py:

Enable per user site-packages directory

set it to False to disable the feature or True to force the feature

ENABLE_USER_SITE = None

If we disable the feature by default it won't be available for a lot of users.

For security reasons we also need it disabled when the getuid() != geteuid() to avoid user supplied code being executed as another user. Defaulting to disabled would mean that security could be left up to the end user to mess up. (many systems do not allow setuid #! scripts but this issue would still apply to things run under sudo)

It sounds like a reasonable and easy implementable idea, at least on Unix. Windows doesn't have getuid() and geteuid(). On the other hand Windows doesn't have the suid bit, too.

I also tried to check if os.stat(main.file).st_uid == os.getuid() but the real main is not available in site.py. It's loaded and assigned much later.

Christian

More information about the Python-Dev mailing list