[Python-bugs-list] [ python-Bugs-425007 ] Python 2.1 installs shared libs with mode 0700
noreply@sourceforge.net
noreply@sourceforge.net
Wed, 16 Jan 2002 06:28:56 -0800
Bugs item #425007, was opened at 2001-05-17 16:28
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470
Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Michael Hudson (mwh)
Summary: Python 2.1 installs shared libs with mode 0700
Initial Comment:
I have gone back and tried Python 1.6 and 2.0. Both
work fine. When I install Python 2.1, everything is
broken. The problem is that when a module is a shared
library (.so), python refuses to load the module. Example:
import os
import sys
import SocketServer
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.1/SocketServer.py", line 126, in ?
import socket
File "/usr/lib/python2.1/socket.py", line 41, in ?
from _socket import *
ImportError: No module named _socket
Now, do a "locate _socket.so" and I get:
/usr/lib/python2.1/site-packages/_socket.so
/usr/lib/python2.1/lib-dynload/_socket.so
Clearly they are there, it's just that Python refuses
to load them.
I made Python 2.1 from source as fetched from the 2.1
tar ball. It makes cleanly. During the installation,
I see some items that I believe to be minor that popup,
but don't currectly expect that they are the problem.
I have tried many times using different configure
options to get this to work, deleting the previous
installation each time. I've even tried installing in
different locations.
As is, Python 2.1 is completely broken for me. Surely
I'm not the only one having this problem, especially
since 1.5, 1.6, and 2.0 all work correctly.
Any help would be great. BTW, doing a "print sys.path"
gives me: ['', '/usr/lib/python2.1',
'/usr/lib/python2.1/plat-linux2',
'/usr/lib/python2.1/lib-tk',
'/usr/lib/python2.1/lib-dynload',
'/usr/lib/python2.1/site-packages']
As you can see, lib-dynload is in the path, so I'm not
really sure what's going on.
----------------------------------------------------------------------
>Comment By: Michael Hudson (mwh)
Date: 2002-01-16 06:28
Message:
Logged In: YES
user_id=6656
I'll do something about this at some point.
Using copy_tree to install shared libraries is gross.
----------------------------------------------------------------------
Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-21 23:24
Message:
Logged In: YES
user_id=149084
INSTALLATION: Confirm. Built with umask 077, group and
others have no permissions in source tree. (Note that if I
su to install, the 077 follows! ok, install with umask of
022, normal for root.). Everything in installation looks ok
except for lib-dynload, which has 700 permissions on files.
No _socket.so in site-packages.
REINSTALLATION: I suspect there is more to this than
distutils...Redo the build with umask 022. Then chmod the
whole previously installed tree to 700 and if you then
repeat the install on top of it you find that while the .py
files have been correctly copied by /usr/bin/install with
644, the .pyc and .pyo are still 700 though recompiled.
This also happens in 1.5.2. The lib-dynload files are 755.
This is with a umask of 022 for both the build user and
root. Finally, delete a few files from lib-dynload, chmod
the rest to 700, and make install again! The deleted files
are restored at 755, the rest stay at 700. In general,
messed up permissions are not fixed by a re-install.
It would seem desirable that re-installing should result in
exactly the same install tree as the initial install,
including permissions, except that any non-distribution
files (e.g. "site-packages") added by the user would be
unaffected. If the user had modified some distribution .py
files they would be reverted by the re-install, which does
seem to be the case. A broken installation could be repaired
by re-installing.
Would that be a reasonable policy? Or is it too difficult to
fix up all the permissions? A compromise might be to delete
the .pyo .pyc before compiling, and explicitly chmod all the
lib-dynload files during install.
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 13:15
Message:
Logged In: YES
user_id=11375
Reclassifying as a Distutils bug.
The install_lib subcommand simply copies the contents of
the BUILD/ tree. It needs to pointedly ignore the umask
and set the proper permissions on the installed files.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-21 12:32
Message:
Logged In: YES
user_id=6380
Assigning this to Andrew -- clearly the setup.py script (or
distutils) needs to be fixed to fix this.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-21 12:24
Message:
Logged In: YES
user_id=6380
I didn't mean to imply that you did something incorrectly.
I just meant that there was some interaction between your
system and Python that didn't work out the way it was
supposed to be. Since Python installs correctly on most
systems, I was implying that there's something unusual in
your system that the Python install procedure doesn't
anticipate.
The mode 0700 for the shared libraries is a big hint at what
was wrong (and if you had done an ls -l of the file when
first reporting this we would have figured out the problem
much quicker). Is perhaps the umask of the user who built
(not installed) the files set to 077? In that case, the
cause is that the "make install" by root doesn't change the
file modes to something more reasonable (I've confirmed that
this indeed happens). I'll look into whether this can be
fixed. I'm changing the subject line of this bug report to
reflect more accurately that the problem is with the file
modes of shared libs.
I still believe that the _socket.so in site-packages could
not have been placed there by the normal Python install
procedure.
----------------------------------------------------------------------
Comment By: Greg Copeland (oracle)
Date: 2001-05-21 08:13
Message:
Logged In: YES
user_id=40173
The problem is that the installation is partially broken. It
didn't install the shared libraries with proper permissions.
When Python installed the shared libs, it installed the libs
as root.root having 0700 permissions. When I tried to
execute it as a normal user, obviously, it fails to load the
shared lib. Python then, incorrectly reports that the shared
lib can not be found. Of course, the correct solution is
for Python to accurately report the problem and to have the
installation always install the libraries with correct
ownership and permission. I don't think I'm asking for too
much here. Seems pretty reasonable to me.
Anyone stating that I did not install correctly is woefully
incorrect. Simply put, the installation is not 100%. As for
some of the libraries existing twice. Well, simply put, the
installation is not 100%.
At any rate, I think it's safe to close this bug but we
might want to add it to the faq-o-matic somewhere or some
such thing.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-20 10:35
Message:
Logged In: YES
user_id=6380
Clearly it's something you have done to yourself. :-) The
question is how to find out what.
Try "python -v" or even "python -vv" and see what it prints
when you try to import _socket. This should give you some
clues (it shows where it searches for modules during
import).
As kbk says, that other _socket.so is mysterious.
----------------------------------------------------------------------
Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-19 17:16
Message:
Logged In: YES
user_id=149084
Well, import SocketServer works ok for me with Python built
both from the 2.1 tar file and the 2.2a0 CVS tree. I'm
running Linux 2.2.5 (RH 6.2) on Pentium.
Did you make clean after changing the configure options?
It is not normal to have _socket.so in .../site-packages; it
should be only in .../lib-dynload. Default installation has
only the README file in site-packages.
Your sys.path looks normal, except that Python default
installs at /usr/local/[bin/lib]. I tried a build targeted
at /usr/[bin/lib] and it was ok.
You could try make clobber, but it's almost as fast to start
over. Try a vanilla installation:
1. delete your install tree @ /usr/local/lib/python2.1
(and/or /usr/lib)
2. delete your source tree from wherever you unpacked the
tar file.
3. untar again, cd to source directory it created
4. without changing any files, and no configure options, run
./configure, then make, then make install
If that doesn't help, what Linux are you running, on what
box, and where did you get your 2.1 tar file?
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470