#88 Make sure ldap bind doesn't block
Closed: wontfix 4 years ago by pbrezina. Opened 14 years ago by jhrozek.

(ticket text reconstructed from IRC discussion with Simo)

Look how to prevent openldap libraris from doing the name resolution themselves and still have things like SASL/GSSAPI work. We do not have code that uses a keytab to auth to the server yet, so it may be necessary to do some extra testing or prototyping.

The main problem is when gssapi libs will want to resolve the server name to get a ticket. Maybe try to see if you can pass a bare ip address to openldap libs but still provide the right server name in the sasl callback.


Fields changed

owner: somebody => mnagy

Fields changed

component: SSSD => LDAP Provider
type: defect => enhancement

Fields changed

milestone: SSSD 0.5.0 => SSSD 0.6.0

Fields changed

doc: => 0
docupdated: => 0
milestone: SSSD 0.6.0 => SSSD 0.7.0
tests: => 0
testsupdated: => 0

Fields changed

milestone: SSSD 0.7.0 => SSSD 1.0 RC

I was under impression that if you pass IP address as a name to name resolution function it will be resolved to this IP address. Is this not the case any more?

Replying to [comment:6 dpal]:

I was under impression that if you pass IP address as a name to name resolution function it will be resolved to this IP address. Is this not the case any more?
Yes, but that isn't important here. What this ticket is about is that libraries that we use do the name resolution themselves. This is a problem for us since that operation can block. And they often need both ip address and host name, so the whole thing can get complicated.

And what I am trying to say is that if you pass IP in as a name it used to short socket DNS lookup to just local translation of the string IP to the IP as an address.
I think it is easy to check if you pass in the IP as string and watch what happens. I hope that it will not go out to DNS at all so it would not block.

Changing summary of this ticket to make it more clear what it is for.

Replying to [comment:8 dpal]:

And what I am trying to say is that if you pass IP in as a name it used to short socket DNS lookup to just local translation of the string IP to the IP as an address.
This is not always the case. If you provide a string IP to the ldap library and use SASL/GSSAPI, the ldap library will use cyrus-sasl library and pass it the same string. The problem is that cyrus-sasl needs (for some SASL plug-ins, like kerberos) both IP and hostname. If you provide an IP it will do a reverse lookup, if you provide a hostname it will lookup the IP address.

summary: convert the LDAP driver to the async resolv interface => Make sure ldap bind doesn't block

Fields changed

milestone: SSSD 1.0 RC => SSSD Deferred

Fields changed

milestone: SSSD Deferred => SSSD 1.1

Fields changed

priority: major => critical

Getting this right is tricky. Deferring to 1.2 to spend more time on it.

milestone: SSSD 1.1 => SSSD 1.2

During discussion today, it was determined that implementing this behavior would require adding code to ensure that all LDAP requests are restartable.

This means encapsulating every LDAP request as a tevent_req. This is a large-scale change and is now out of scope for 1.2.

milestone: SSSD 1.2 => SSSD 1.3

Fixed in 56d8d19

fixedin: => 1.4.0
resolution: => fixed
status: new => closed

Fields changed

resolution: fixed =>
status: closed => reopened

The issue is reopened and deferred to future release.

fixedin: 1.4.0 =>
milestone: SSSD 1.5.0 => SSSD 1.6.0

Fields changed

coverity: =>
milestone: SSSD 1.6.0 => SSSD Deferred
priority: critical => major
upgrade: => 0

Fields changed

rhbz: => 0

Metadata Update from @jhrozek:
- Issue assigned to mnagy
- Issue set to the milestone: SSSD Patches welcome

7 years ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

4 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1130

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata