#952 sssd leaves LDAP socket in non-blocking mode after connecting
Closed: Fixed None Opened 10 years ago by ralf.

Since 1.5.9 the way to open the LDAP connection was change to a combination of socket(), connect() and ldap_init_fd() (see ticket#905). sssd tries to open the connection asynchronously, setting the O_NONBLOCK flag before calling connect(). There seems to be even logic to reset that flag before handing over the socket to libldap. That however doesn't work correctly so libldap will use the non-blocking socket. This doesn't work correctly with current libldap releases.

I'll submit a patch to the sssd-devel list soon.


We have been using non-blocking sockets way before changing the way we connect, because we have always been asynchronous.
The connection changes were made to make also the connection asynchronous.

Can you be a bit more specific about what is not working if the fd is asynchronous?

Replying to [comment:1 simo]:

We have been using non-blocking sockets way before changing the way we connect, because we have always been asynchronous.

Hm, where? I can't seem to find that. At least sssd 1.5.8 doesn't seem to touch the flags of the LDAP connection's socket. And by default libldap is using blocking I/O.

The connection changes were made to make also the connection asynchronous.

Can you be a bit more specific about what is not working if the fd is asynchronous?

I saw erroneous behavior on a system that had a missconfigured SSL setup (the CA cert was not configured correctly). Usually in such a case ldap_install_tls would return with an error and sssd would log something like this in syslog:

Could not start TLS encryption. error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed certificate in certificate chain)

On this system however I only got that sometimes. Most of the times I just got:
sssd[be[default]]: LDAP connection error: unknown error

And even debug_level=10 the debug log did not indicate any kind of TLS problem. While investigating that problem I that O_NONBLOCK was set on the socket and that the SSL handshake wasn't really completed after ldap_install_tls returned LDAP_SUCCESS. And then I noticed this comment in the ldap_int_tls_start() function of the OpenLDAP libraries (which is called by ldap_install_tls() ):

/
- Fortunately, the lib uses blocking io...
/

This appears directly before the call to initiate the SSL handshake and gives to me a pretty good hint that libldap is not able to deal correctly with non-blocking sockets. At least when linking against openssl it doesn't handle the return values for SSL_connect() correctly for the non-blocking case. I can't currently test with NSS but I to me it looks as if there are similar problems.

Replying to [ticket:952 ralf]:

I'll submit a patch to the sssd-devel list soon.
I just attached my suggested patch here for now. If you prefer to have it on the list as well please let me know.

I think Ralf is right here. I have checked the OpenLDAP client libraries and it does not use O_NONBLOCK on the sockets it will create internally. So we do not loose anything if we do not set O_NONBLOCK on the socket we create.

A reason why we haven't seen this before might be that the NSS TLS/SSL backend checks if the socket is on blocking or non-blocking mode. Maybe this might be a good enhancement for the OpenSSL backend, too?

FWIW, the patch worked fine during my testing.

Fixed by:
- 2a64465 (master)
- 8121d1c (sssd-1-6)
- 0e10757 (sssd-1-5)

component: SSSD => LDAP Provider
milestone: NEEDS_TRIAGE => SSSD 1.5.13
patch: 0 => 1
priority: major => critical
resolution: => fixed
status: new => closed

Fields changed

rhbz: => 0

Metadata Update from @ralf:
- Issue set to the milestone: SSSD 1.5.13

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/1994

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