This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Automatic *libc.so loading behaviour
Type: behavior Stage: resolved
Components: ctypes Versions: Python 3.2, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: dgoulet, meador.inge, python-dev, sbarthelemy
Priority: normal Keywords: patch

Created on 2012-02-09 21:10 by dgoulet, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
issue13979-v0.patch meador.inge, 2012-02-13 03:46 Patch against 3.2 tip
Messages (3)
msg152988 - (view) Author: David Goulet (dgoulet) Date: 2012-02-09 21:10
I'm working with the LTTng (Linux Tracing) team and we came across a problem with our user-space tracer and Python default behaviour. We provide a libc wrapper that instrument free() and malloc() and is usable with a simple LD_PRELOAD.

This lib *was* named "liblttng-ust-libc.so" and we came across python software registering to our trace registry daemon (meaning that somehow the python binary is using our in-process library). We dig a bit and found this:

Lib/ctypes/utils.py:

def _findLib_ldconfig(name):
       # XXX assuming GLIBC's ldconfig (with option -p)
       expr = r'/[^\(\)\s]*lib%s\.[^\(\)\s]*' % re.escape(name)
       res = re.search(expr,
                       os.popen('/sbin/ldconfig -p 2>/dev/null').read())

and, at least, also found in _findLib_gcc(name) and _findSoname_ldconfig(name).

This cause Python to use any library ending with "libc.so" to be loaded....

I don't know the reasons behind this but we are concerned about "future issues" with this kind of behaviour.

Thanks
msg153245 - (view) Author: Meador Inge (meador.inge) * (Python committer) Date: 2012-02-13 03:46
'find_library' itself actually loads no libraries.  I suspect what happened was that the following code in the 'uuid' module coupled with the 'find_library' bug caused 'liblttng-ust-libc.so' to be loaded:

    for libname in ['uuid', 'c']:
        try:
            lib = ctypes.CDLL(ctypes.util.find_library(libname))
        except:
            continue
        if hasattr(lib, 'uuid_generate_random'):
            _uuid_generate_random = lib.uuid_generate_random
        if hasattr(lib, 'uuid_generate_time'):
            _uuid_generate_time = lib.uuid_generate_time

This issue was fixed in 3.3 as a part of the optimization done in issue11258. I can still reproduce the problem in 2.7 and 3.2.

I am just going to backport the 3.3 regex to 2.7 and 3.2.  This is not an issue for the '_findLib_gcc' regex because the GCC output has a different format.  '_findLib_ldconfig' is never actually called so I removed it.  Patch attached.
msg153329 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2012-02-14 04:25
New changeset ac362fb3b86b by Meador Inge in branch '3.2':
Issue #13979: Fix ctypes.util.find_library ldconfig regex
http://hg.python.org/cpython/rev/ac362fb3b86b

New changeset be41abd74949 by Meador Inge in branch '2.7':
Issue #13979: Fix ctypes.util.find_library ldconfig regex
http://hg.python.org/cpython/rev/be41abd74949

New changeset 096e856a01aa by Meador Inge in branch 'default':
Issue #13979: Fix ctypes.util.find_library ldconfig regex
http://hg.python.org/cpython/rev/096e856a01aa
History
Date User Action Args
2022-04-11 14:57:26adminsetgithub: 58187
2012-02-14 04:27:18meador.ingesetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2012-02-14 04:25:49python-devsetnosy: + python-dev
messages: + msg153329
2012-02-13 15:28:10sbarthelemysetnosy: + sbarthelemy
2012-02-13 03:46:10meador.ingesetfiles: + issue13979-v0.patch
versions: - Python 3.3
messages: + msg153245

keywords: + patch
stage: needs patch -> patch review
2012-02-09 21:41:09pitrousetnosy: + meador.inge
stage: needs patch

versions: + Python 3.2, Python 3.3, - Python 2.6
2012-02-09 21:10:07dgouletcreate