Open mazerj opened 6 years ago
Just discovered another example of the weakref problem. The following is from a fresh install and update of stock anaconda2 python 2.7 (installed and then conda update --all; conda install virtualenv
):
[#2] mazer@glacier $ ~/anaconda2/bin/virtualenv env
New python executable in /auto/share/src/pype3/env/bin/python
Installing setuptools, pip, wheel...
Complete output from command /auto/share/src/pype3/env/bin/python - setuptools pip wheel:
Traceback (most recent call last):
File "<stdin>", line 11, in <module>
File "/auto/home/mazer/anaconda2/lib/python2.7/site-packages/virtualenv_support/pip-9.0.3-py2.py3-none-any.whl/pip/__init__.py", line 5, in <module>
File "/auto/home/mazer/anaconda2/lib/python2.7/logging/__init__.py", line 26, in <module>
import sys, os, time, cStringIO, traceback, warnings, weakref, collections
File "/auto/home/mazer/anaconda2/lib/python2.7/weakref.py", line 14, in <module>
from _weakref import (
ImportError: cannot import name _remove_dead_weakref
----------------------------------------
...Installing setuptools, pip, wheel...done.
Traceback (most recent call last):
File "/auto/home/mazer/anaconda2/bin/virtualenv", line 11, in <module>
sys.exit(main())
File "/auto/home/mazer/anaconda2/lib/python2.7/site-packages/virtualenv.py", line 712, in main
symlink=options.symlink)
File "/auto/home/mazer/anaconda2/lib/python2.7/site-packages/virtualenv.py", line 953, in create_environment
download=download,
File "/auto/home/mazer/anaconda2/lib/python2.7/site-packages/virtualenv.py", line 904, in install_wheel
call_subprocess(cmd, show_stdout=False, extra_env=env, stdin=SCRIPT)
File "/auto/home/mazer/anaconda2/lib/python2.7/site-packages/virtualenv.py", line 796, in call_subprocess
% (cmd_desc, proc.returncode))
OSError: Command /auto/share/src/pype3/env/bin/python - setuptools pip wheel failed with error code 1
I'm thinking that somehow the anaconda binary is linking against system libs even though LD_LIBRARY is empty, though for the life of my I can't figure out where or reliably predict when it's going to happen. Again, this is a pretty much stock Mint 18.2 installation (same as initial post above).
I see the same behaviour whenever setting the SUID bit or when adding capabilities to the Python binary. You're correct that the library search path is being overridden with the system path. In fact, it loads the system Python interpreter when executing the anaconda wrapper application because that's the libpython.so that it finds.
Actually, same here -- I originally came across the problem with a more complicated suid-root script I wrote to start a real-time data collection process, but this one seemed easier to post so others could replicate..
So, is this a bug? I would have thought a bug preventing installation of virtualenv
would have set off alarm bells all over the place :-)
Actual Behavior
Anaconda distribution binary behaves differently when importing weakref.py (triggered by
import numpy as np
, for example) when the suid-bit is set.This is really obscure, but I'm running the python interpreter from a thin C wrapper program and if the wrapper is suid-root,
import weakref.py
fails. Same program, with suid-bit cleared and if works. Doesn't happen with the stock python2.7 interpreter provided by distribution. Interestingly, if the suid-bit is set, but seteuid() is used to change the UID back to the a non-root value, it still fails. Demo below:Expected Behavior
Execution should be same regardless of suid-bit status.
Steps to Reproduce
Compile and run the following program (makefile below):
Anaconda or Miniconda version:
Anaconda2-5.1.0-Linux-x86_64
Operating System:
conda info
conda list --show-channel-urls