(original) (raw)



On 1/13/08, Christian Heimes <lists@cheimes.de> wrote:

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:

Good point, leave it on by default.


# 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.


Is sys.argv\[0\] available at that point?