RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1104627 - openldap-libs performs blocking name resolution during initalization
Summary: openldap-libs performs blocking name resolution during initalization
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openldap
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jan Synacek
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-04 11:28 UTC by Jakub Hrozek
Modified: 2014-06-24 07:04 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-24 07:04:08 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jakub Hrozek 2014-06-04 11:28:57 UTC
Description of problem:
We have a code in SSSD that initializes TLS connection parameters. When this code is called, I'm observing a name resolution done by the openldap libraries.

This breaks SSSD in cases the nameserver being contacted is not reachable as the startup blocks and in some cases, the internal IPC communication might time out.

Version-Release number of selected component (if applicable):
openldap-2.4.39-3.el7

How reproducible:
always

Steps to Reproduce:
1. put a broken DNS record into /etc/resolv.conf (1.1.1.1 does the trick)
2. start SSSD
3.

Actual results:
startup hangs, internal IPC communication errors.

Expected results:
Setting an option should have immediate effect. The hostname canonicalization should be optional, caller should be able to pass in the hostname himself.

Additional info:
This is the full backtrace I'm seeing:
#0  0x00007fda39c80a70 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fda38d17e0d in send_dg (resplen2=0x0, anssizp2=0x0, ansp2=0x0, 
    anscp=0x7fff2548cb30, gotsomewhere=<synthetic pointer>, 
    v_circuit=<synthetic pointer>, ns=0, terrno=0x7fff2548bab0, anssizp=0x7fff2548bbf0, 
    ansp=0x7fff2548baa8, buflen2=0, buf2=0x0, buflen=36, buf=0x7fff2548bc20 "\tg\001", 
    statp=0x7fda39f533e0 <_res.5>) at res_send.c:1059
#2  __libc_res_nsend (statp=statp@entry=0x7fda39f533e0 <_res.5>, 
    buf=buf@entry=0x7fff2548bc20 "\tg\001", buflen=<optimized out>, buf2=buf2@entry=0x0, 
    buflen2=buflen2@entry=0, ans=ans@entry=0x7fff2548c700 "", anssiz=anssiz@entry=1024, 
    ansp=ansp@entry=0x7fff2548cb30, ansp2=ansp2@entry=0x0, nansp2=nansp2@entry=0x0, 
    resplen2=resplen2@entry=0x0) at res_send.c:556
#3  0x00007fda38d15d47 in __GI___libc_res_nquery (
    statp=statp@entry=0x7fda39f533e0 <_res.5>, 
    name=0x7fff2548d140 "client.example.com", class=class@entry=1, type=type@entry=1, 
    answer=answer@entry=0x7fff2548c700 "", anslen=anslen@entry=1024, 
    answerp=answerp@entry=0x7fff2548cb30, answerp2=answerp2@entry=0x0, 
    nanswerp2=nanswerp2@entry=0x0, resplen2=resplen2@entry=0x0) at res_query.c:226
#4  0x00007fda38d16963 in __libc_res_nquerydomain (domain=0x0, resplen2=0x0, 
    nanswerp2=0x0, answerp2=0x0, answerp=0x7fff2548cb30, anslen=1024, 
    answer=0x7fff2548c700 "", type=1, class=1, name=0x7fff2548d140 "client.example.com", 
    statp=0x7fda39f533e0 <_res.5>) at res_query.c:582
#5  __GI___libc_res_nsearch (statp=0x7fda39f533e0 <_res.5>, 
    name=name@entry=0x7fff2548d140 "client.example.com", class=class@entry=1, 
    type=type@entry=1, answer=answer@entry=0x7fff2548c700 "", anslen=anslen@entry=1024, 
    answerp=0x7fff2548cb30, answerp2=answerp2@entry=0x0, nanswerp2=nanswerp2@entry=0x0, 
    resplen2=resplen2@entry=0x0) at res_query.c:378
#6  0x00007fda2f2777e4 in __GI__nss_dns_gethostbyname3_r (
    name=name@entry=0x7fff2548d140 "client.example.com", af=af@entry=2, 
    result=result@entry=0x7fff2548d120, buffer=buffer@entry=0x1f33590 "\177", 
    buflen=buflen@entry=992, errnop=errnop@entry=0x7fda3d8966a0, 
    h_errnop=h_errnop@entry=0x7fff2548d10c, ttlp=ttlp@entry=0x0, canonp=canonp@entry=0x0)
    at nss_dns/dns-host.c:192
#7  0x00007fda2f277af0 in _nss_dns_gethostbyname_r (
    name=0x7fff2548d140 "client.example.com", result=0x7fff2548d120, 
    buffer=0x1f33590 "\177", buflen=992, errnop=0x7fda3d8966a0, h_errnop=0x7fff2548d10c)
    at nss_dns/dns-host.c:273
#8  0x00007fda39c9e163 in __gethostbyname_r (
    name=name@entry=0x7fff2548d140 "client.example.com", 
    resbuf=resbuf@entry=0x7fff2548d120, buffer=0x1f33590 "\177", buflen=buflen@entry=992, 
    result=result@entry=0x7fff2548d118, h_errnop=h_errnop@entry=0x7fff2548d10c)
    at ../nss/getXXbyYY_r.c:266
#9  0x00007fda3bb1b3de in ldap_pvt_gethostbyname_a (
    name=name@entry=0x7fff2548d140 "client.example.com", 
    resbuf=resbuf@entry=0x7fff2548d120, buf=buf@entry=0x7fff2548d110, 
    result=result@entry=0x7fff2548d118, herrno_ptr=herrno_ptr@entry=0x7fff2548d10c)
    at util-int.c:350
#10 0x00007fda3bb1b5d0 in ldap_pvt_get_fqdn (name=0x7fff2548d140 "client.example.com", 
    name@entry=0x0) at util-int.c:748
#11 0x00007fda3bb19b47 in ldap_int_initialize (
    gopts=gopts@entry=0x7fda3bd40000 <ldap_int_global_options>, dbglvl=dbglvl@entry=0x0)
    at init.c:645
---Type <return> to continue, or q <return> to quit---
#12 0x00007fda3bb1a627 in ldap_set_option (ld=0x0, option=24582, invalue=0x7fff2548d2b0)
    at options.c:446
#13 0x00007fda30951cf6 in setup_tls_config (basic_opts=0x1f30450)
    at src/providers/ldap/sdap.c:533
#14 0x00007fda308214b3 in ldap_id_init_internal (bectx=0x1f12b40, ops=0x1f12cb0, 
    pvt_data=0x7fff2548d5e8) at src/providers/ldap/ldap_init.c:146
#15 0x00007fda30821ba0 in sssm_ldap_id_init (bectx=0x1f12b40, ops=0x1f12cb0, 
    pvt_data=0x1f12cb8) at src/providers/ldap/ldap_init.c:199
#16 0x000000000041b227 in load_backend_module (ctx=0x1f12b40, bet_type=BET_ID, 
    bet_info=0x1f12ca8, default_mod_name=0x0) at src/providers/data_provider_be.c:2346
#17 0x000000000041ce4c in be_process_init (mem_ctx=0x1f0ba80, 
    be_domain=0x1f093f0 "localipaldap", ev=0x1f0a630, cdb=0x1f0bb90)
    at src/providers/data_provider_be.c:2520
#18 0x000000000041fde6 in main (argc=3, argv=0x7fff2548e008)
    at src/providers/data_provider_be.c:2743

The snippet of the code that generated the backtrace reads:
 735         /* LDAP_OPT_X_TLS_REQUIRE_CERT has to be set as a global option,
 736          * because the SSL/TLS context is initialized from this value. */
 737         ret = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT,
 738                               &ldap_opt_x_tls_require_cert);
 739         if (ret != LDAP_OPT_SUCCESS) {
 740             DEBUG(SSSDBG_CRIT_FAILURE,
 741                   "ldap_set_option failed: %s\n",sss_ldap_err2string(ret));
 742             return EIO;
 743         }

Comment 2 Jan Synacek 2014-06-13 06:20:02 UTC
I asked upstream about this:
http://www.openldap.org/lists/openldap-technical/201406/msg00051.html

Comment 3 Jakub Hrozek 2014-06-18 09:40:20 UTC
Thanks, I'm following openldap-technical so I'll chime in.

Comment 4 Jan Synacek 2014-06-24 07:04:08 UTC
Unless upstream is not convinced otherwise, this is not a bug.


Note You need to log in before you can comment on or make changes to this bug.