Bug 6610 - NSS modules should be dlopen()ed with RTLD_DEEPBIND
Summary: NSS modules should be dlopen()ed with RTLD_DEEPBIND
Status: RESOLVED WONTFIX
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-09 18:33 UTC by Petr Baudis
Modified: 2020-03-08 14:25 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Baudis 2008-06-09 18:33:37 UTC
nss/nsswitch.c should dlopen() the NSS modules with RTLD_DEEPBIND so that the
application symbols will not interfere with symbols the NSS module is using.

A practical example (pointed out by Michael Meeks) is nss_ldap + Thunderbird
failing, since both use incompatible LDAP libraries with some symbols clashing;
nss_ldap will use the Thunderbird LDAP library symbols in preference to these of
its own library, resulting in a crash. Deepbinding should solve this problem,
and I can think of no bad side-effects (in sane situations).
Comment 1 Mike Frysinger 2008-12-29 20:44:20 UTC
i tried merging this into the Gentoo glibc package, but things went badly for
mozilla users.  feel like having a look ?

http://bugs.gentoo.org/252302
Comment 2 Petr Baudis 2010-06-11 14:01:50 UTC
By now, plenty of bad side-effects popped up mainly due to the fact that custom
malloc() overrides do not work - the NSS module will ignore them, but will try
to free() pointers allocated by glibc using the overriden malloc(). It's
probably best to require NSS modules not to pollute namespace.
Comment 3 Florian Weimer 2020-03-08 14:25:49 UTC
Note that by now, nss_ldap with its in-process LDAP processing is considered a design mistake. The successor, nss_ldapd, performs all LDAP handling in a dedicated daemon, so that the NSS module itself does not depend on any LDAP libraries. This avoids symbol binding issues due to conflicting LDAP libraries. (It also allows the client to use some secret not known to all local users to authenticate to the LDAP server.)