[Distutils] Setuptools Bug: all files installed +x

[Cliff Wells]

On Tue, 2008-04-22 at 12:19 -0400, Phillip J. Eby wrote:
> At 11:49 AM 4/22/2008 -0400, Pete wrote:
> >On Apr 21, 2008, at 6:01 PM, Phillip J. Eby wrote:
> >
> >>At 04:23 PM 4/21/2008 -0400, Pete wrote:
> >>>I'm not looking for explicit testing support from setuptools for
> >>>testing here - I'm just asking that a bug that breaks a 3rd party
> >>>testing package be fixed.
> >>
> >>You haven't stated anything yet that sounds like an actual bug to me.
> >
> >What about the dangerous & broken complaint?
> 
> Which I don't yet understand, let alone agree with.  Simply asserting 
> over and over that it's bad and dangerous doesn't help.

I thought his explanation was rather clear. Here's a valid Python file
that will make you unhappy if you execute it from the shell:

rm = 0   # shell error, no effect
rf = 1   # another shell error
home = 8  # etc...
result=`rm -rf /home` 

In Python you get '0', in Bash you get a wiped out home directory. 

Yes, it's quite contrived.  But his point about "import" also being a
typical command on *nix (runs an Imagemagick binary) points out that
there's probably even more concerns that we aren't thinking of. 
This is especially a concern because shell scripts don't abort on error
(so you could conceivably make it quite a ways through a Python file
until you hit some random name that happens to be a valid Unix command).

It's probably unlikely that someone would accidentally run one of these
modules inadvertently.  But "highly unlikely" is also not "secure".
I've certainly run the wrong thing on accident because Bash's
tab-completion caught me off-guard.

He's also right in that arbitrarily setting the execute bit apparently
serves no explainable purpose (otherwise I assume you'd have provided an
explanation by now), so the onus of explaining why this is a desirable
behavior comes back to setuptools.

> One thing that you particularly seem to be missing is that the 
> distutils also ignore a Python module's source permissions -- whether 
> they come from a tarball or not.

I'm not sure why any file in site-packages would need the execute bit
set.  Executable scripts are (or should be) installed elsewhere.  If the
bit *must* be set one way or the other, then it should be turned off by
default.

Regards,
Cliff