URL: https://github.com/SSSD/sssd/pull/67 Author: lslebodn Title: #67: UTIL: Unset O_NONBLOCK for ldap connection Action: opened
PR body: """ Before the commit 75e66c388862a4ba05afe0791c5503226395bad0, the flag O_NONBLOCK was set only for the connect syscall in request sssd_async_connect_send -> sssd_async_connect_send. Such change was done for secrets provider.
However, if ldap is compiled with gnutls it caused problems with start_tls and ldaps.
OpenLDAP Server log: 5810cf2f connection_get(23): got connid=1042 5810cf2f connection_read(23): checking for input on id=1042 TLS: error: accept - force handshake failure: errno 11 - moznss error -12234 TLS: can't accept: TLS error -12234:SSL received an unexpected Application Data record.. 5810cf2f connection_read(23): TLS accept failure error=-1 id=1042, closing 5810cf2f connection_close: conn=1042 sd=23
sssd domain log: [simple_bind_send] (0x0100): Executing simple bind as: uid=user1,dc=example,dc=com [simple_bind_send] (0x2000): ldap simple bind sent, msgid = 2 [sdap_op_add] (0x2000): New operation 2 timeout 6 [sdap_process_result] (0x2000): Trace: sh[0x151c240], connected[1], ops[0x1515700], ldap[0x1511bd0] [sdap_process_result] (0x2000): Trace: end of ldap_result list [sdap_process_result] (0x2000): Trace: sh[0x151c240], connected[1], ops[0x1515700], ldap[0x1511bd0] [sdap_process_result] (0x0040): ldap_result error: [Can't contact LDAP server] [sdap_handle_release] (0x2000): Trace: sh[0x151c240], connected[1], ops[0x1515700], ldap[0x1511bd0], destructor_lock[0], release_memory[0] [remove_connection_callback] (0x4000): Successfully removed connection callback. [sdap_op_destructor] (0x1000): Abandoning operation 2 [dp_req_done] (0x0400): DP Request [PAM Authenticate #3]: Request handler finished [0]: Success [_dp_req_recv] (0x0400): DP Request [PAM Authenticate #3]: Receiving request data. [dp_req_destructor] (0x0400): DP Request [PAM Authenticate #3]: Request removed. [dp_req_destructor] (0x0400): Number of active DP request: 0 [dp_method_enabled] (0x0400): Target selinux is not configured [dp_pam_reply] (0x1000): DP Request [PAM Authenticate #3]: Sending result [4][LDAP]
Resolves: https://fedorahosted.org/sssd/ticket/3189 """
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/67/head:pr67 git checkout pr67
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
sumit-bose commented: """ Thank you for digging into this and finding the connection to gnutls. Do you think this is an issue which should be solved in OpenLDAP or gnutls as well, or is it really the responsibility of the caller to make sure O_NONBLOCK is not set? If yes, is this documented?
"""
See the full comment at https://github.com/SSSD/sssd/pull/67#issuecomment-256582670
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
lslebodn commented: """
Thank you for digging into this and finding the connection to gnutls. Do you think this is an issue which should be solved in OpenLDAP or gnutls as well, or is it really the responsibility of the caller to make sure O_NONBLOCK is not set? If yes, is this documented?
Maybe Nikos would know @nmav """
See the full comment at https://github.com/SSSD/sssd/pull/67#issuecomment-256585196
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
nmav commented: """ I don't quite understand what the fix is about nor how it relates to gnutls. Is it about wrong handling of the client socket? To know whether the issue is on the gnutls server, I'll need more information from the server side (gnutls version, a run with GNUTLS_DEBUG_LEVEL set to 6 or more, and a capture of the session). """
See the full comment at https://github.com/SSSD/sssd/pull/67#issuecomment-256587092
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
nmav commented: """ I don't quite understand what the fix is about nor how it relates to gnutls. Is it about wrong handling of the client socket? To know whether the issue is on the gnutls server, I'll need more information from the server side (gnutls version, a server run with GNUTLS_DEBUG_LEVEL set to 6 or more, and a capture of the session). """
See the full comment at https://github.com/SSSD/sssd/pull/67#issuecomment-256587092
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
lslebodn commented: """ client log + gnutls debug ``` (Thu Oct 27 11:20:35 2016) [sssd[be[LDAP]]] [simple_bind_send] (0x0100): Executing simple bind as: uid=mof_user1,dc=example,dc=com gnutls[5]: REC[0x1a380b0]: Preparing Packet Application Data(23) with length: 85 and min pad: 0 gnutls[5]: REC[0x1a380b0]: Sent Packet[2] Application Data(23) in epoch 0 and length: 90 (Thu Oct 27 11:20:35 2016) [sssd[be[LDAP]]] [simple_bind_send] (0x2000): ldap simple bind sent, msgid = 2 (Thu Oct 27 11:20:35 2016) [sssd[be[LDAP]]] [sdap_op_add] (0x2000): New operation 2 timeout 6 (Thu Oct 27 11:20:35 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0x1a30cc0], connected[1], ops[0x1a2f660], ldap[0x1a48b60] (Thu Oct 27 11:20:35 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0x1a30cc0], connected[1], ops[0x1a2f660], ldap[0x1a48b60] gnutls[5]: REC[0x1a380b0]: SSL 3.3 Handshake packet received. Epoch 0, length: 1124 gnutls[5]: REC[0x1a380b0]: Expected Packet Application Data(23) gnutls[5]: REC[0x1a380b0]: Received Packet Handshake(22) with length: 1124 gnutls[5]: REC[0x1a380b0]: Decrypted Packet[0] Handshake(22) with length: 1124 gnutls[3]: ASSERT: handshake.c[_gnutls_recv_hello_request]:3384 gnutls[3]: ASSERT: record.c[_gnutls_recv_in_buffers]:1323 gnutls[3]: ASSERT: record.c[_gnutls_recv_int]:1468 (Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x0040): ldap_result error: [Can't contact LDAP server] (Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [sdap_handle_release] (0x2000): Trace: sh[0x1a30cc0], connected[1], ops[0x1a2f660], ldap[0x1a48b60], destructor_lock[0], release_memory[0] (Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [sdap_op_destructor] (0x1000): Abandoning operation 2 gnutls[5]: REC[0x1a380b0]: Preparing Packet Application Data(23) with length: 8 and min pad: 0 gnutls[5]: REC[0x1a380b0]: Sent Packet[3] Application Data(23) in epoch 0 and length: 13 gnutls[3]: ASSERT: buffers.c[_gnutls_io_write_flush]:694 gnutls[5]: REC: Sending Alert[1|0] - Close notify gnutls[5]: REC[0x1a380b0]: Preparing Packet Alert(21) with length: 2 and min pad: 0 gnutls[5]: REC[0x1a380b0]: Sent Packet[4] Alert(21) in epoch 0 and length: 7 (Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [dp_req_done] (0x0400): DP Request [PAM Authenticate #5]: Request handler finished [0]: Success (Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [_dp_req_recv] (0x0400): DP Request [PAM Authenticate #5]: Receiving request data. (Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400): DP Request [PAM Authenticate #5]: Request removed. (Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400): Number of active DP request: 0 (Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [dp_method_enabled] (0x0400): Target selinux is not configured (Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [dp_pam_reply] (0x1000): DP Request [PAM Authenticate #5]: Sending result [4][LDAP] (Thu Oct 27 11:20:36 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x8c86e0 (Thu Oct 27 11:20:36 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x8bbdb0 (Thu Oct 27 11:20:36 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Oct 27 11:20:36 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [4 (System error)][LDAP] (Thu Oct 27 11:20:36 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [4]: System error. (Thu Oct 27 11:20:36 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 21 (Thu Oct 27 11:20:36 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x8c8d30][16] gnutls[3]: ASSERT: buffers.c[_gnutls_io_write_flush]:694 gnutls[5]: REC: Sending Alert[1|0] - Close notify gnutls[5]: REC[0x1a380b0]: Preparing Packet Alert(21) with length: 2 and min pad: 0 gnutls[3]: ASSERT: buffers.c[_gnutls_writev_emu]:462 gnutls[2]: WRITE: -1 returned from 0x19e78c0, errno: 9 gnutls[3]: ASSERT: buffers.c[errno_to_gerr]:228 gnutls[3]: ASSERT: buffers.c[_gnutls_io_write_flush]:720 gnutls[3]: ASSERT: record.c[_gnutls_send_tlen_int]:554 gnutls[3]: ASSERT: record.c[gnutls_bye]:302 gnutls[5]: REC[0x1a380b0]: Start of epoch cleanup gnutls[5]: REC[0x1a380b0]: End of epoch cleanup gnutls[5]: REC[0x1a380b0]: Epoch #0 freed gnutls[5]: REC[0x1a380b0]: Epoch #1 freed (Thu Oct 27 11:20:40 2016) [sssd[pam]] [pam_initgr_cache_remove] (0x2000): [mof_user1] removed from PAM initgroup cache ``` """
See the full comment at https://github.com/SSSD/sssd/pull/67#issuecomment-256591142
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
lslebodn commented: """ related openldap server (witn nss) log: ``` tls_read: want=5, got=5 0000: 17 03 03 00 55 ....U tls_read: want=85, got=85 0000: 30 53 02 01 02 60 2f 02 01 03 04 1f 75 69 64 3d 0S...`/.....uid= 0010: 6d 6f 66 5f 75 73 65 72 31 2c 64 63 3d 65 78 61 mof_user1,dc=exa 0020: 6d 70 6c 65 2c 64 63 3d 63 6f 6d 80 09 53 65 63 mple,dc=com..Sec 0030: 72 65 74 31 32 33 a0 1d 30 1b 04 19 31 2e 33 2e ret123..0...1.3. 0040: 36 2e 31 2e 34 2e 31 2e 34 32 2e 32 2e 32 37 2e 6.1.4.1.42.2.27. 0050: 38 2e 35 2e 31 8.5.1 tls_write: want=7, written=7 0000: 15 03 03 00 02 02 0a ....... TLS: error: accept - force handshake failure: errno 13 - moznss error -12234 TLS: can't accept: TLS error -12234:SSL received an unexpected Application Data record.. 5811c6e4 connection_read(21): TLS accept failure error=-1 id=1001, closing 5811c6e4 connection_closing: readying conn=1001 sd=21 for close 5811c6e4 connection_close: conn=1001 sd=21 5811c6e4 daemon: removing 21 5811c6e4 daemon: activity on 1 descriptor 5811c6e4 daemon: activity on:5811c6e4 5811c6e4 conn=1001 fd=21 closed (TLS negotiation failure) ``` """
See the full comment at https://github.com/SSSD/sssd/pull/67#issuecomment-256591331
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
lslebodn commented: """ and client + gnutls debug without O_NONBLOCK ``` (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [simple_bind_send] (0x0100): Executing simple bind as: uid=mof_user1,dc=example,dc=com gnutls[5]: REC[0xc31720]: Preparing Packet Application Data(23) with length: 86 and min pad: 0 gnutls[5]: REC[0xc31720]: Sent Packet[2] Application Data(23) in epoch 1 and length: 115 (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [simple_bind_send] (0x2000): ldap simple bind sent, msgid = 2 (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [sdap_op_add] (0x2000): New operation 2 timeout 6 (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0xc19510], connected[1], ops[0xc1fe40], ldap[0xc15f50] (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0xc19510], connected[1], ops[0xc1fe40], ldap[0xc15f50] gnutls[5]: REC[0xc31720]: SSL 3.3 Application Data packet received. Epoch 0, length: 73 gnutls[5]: REC[0xc31720]: Expected Packet Application Data(23) gnutls[5]: REC[0xc31720]: Received Packet Application Data(23) with length: 73 gnutls[5]: REC[0xc31720]: Decrypted Packet[1] Application Data(23) with length: 49 (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_BIND] (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [simple_bind_done] (0x2000): Server returned control [1.3.6.1.4.1.42.2.27.8.5.1]. (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [simple_bind_done] (0x1000): Password Policy Response: expire [-1] grace [-1] error [No error]. (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [simple_bind_done] (0x0400): Bind result: Success(0), no errmsg set (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [sdap_op_destructor] (0x2000): Operation 2 finished (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [auth_bind_user_done] (0x4000): Found ppolicy data, assuming LDAP password policies are active. (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [sdap_handle_release] (0x2000): Trace: sh[0xc19510], connected[1], ops[(nil)], ldap[0xc15f50], destructor_lock[0], release_memory[0] (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. gnutls[5]: REC[0xc31720]: Preparing Packet Application Data(23) with length: 7 and min pad: 0 gnutls[5]: REC[0xc31720]: Sent Packet[3] Application Data(23) in epoch 1 and length: 36 gnutls[3]: ASSERT: buffers.c[_gnutls_io_write_flush]:694 gnutls[5]: REC: Sending Alert[1|0] - Close notify gnutls[5]: REC[0xc31720]: Preparing Packet Alert(21) with length: 2 and min pad: 0 gnutls[5]: REC[0xc31720]: Sent Packet[4] Alert(21) in epoch 1 and length: 31 gnutls[3]: ASSERT: buffers.c[_gnutls_io_write_flush]:694 gnutls[5]: REC: Sending Alert[1|0] - Close notify gnutls[5]: REC[0xc31720]: Preparing Packet Alert(21) with length: 2 and min pad: 0 gnutls[3]: ASSERT: buffers.c[_gnutls_writev_emu]:462 gnutls[2]: WRITE: -1 returned from 0xbcbd60, errno: 9 gnutls[3]: ASSERT: buffers.c[errno_to_gerr]:228 gnutls[3]: ASSERT: buffers.c[_gnutls_io_write_flush]:720 gnutls[3]: ASSERT: record.c[_gnutls_send_tlen_int]:554 gnutls[3]: ASSERT: record.c[gnutls_bye]:302 gnutls[5]: REC[0xc31720]: Start of epoch cleanup gnutls[5]: REC[0xc31720]: End of epoch cleanup gnutls[5]: REC[0xc31720]: Epoch #1 freed (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [dp_req_done] (0x0400): DP Request [PAM Authenticate #3]: Request handler finished [0]: Success (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [_dp_req_recv] (0x0400): DP Request [PAM Authenticate #3]: Receiving request data. (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400): DP Request [PAM Authenticate #3]: Request removed. (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400): Number of active DP request: 0 (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [dp_method_enabled] (0x0400): Target selinux is not configured (Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [dp_pam_reply] (0x1000): DP Request [PAM Authenticate #3]: Sending result [0][LDAP] ``` """
See the full comment at https://github.com/SSSD/sssd/pull/67#issuecomment-256595910
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
lslebodn commented: """ client log + gnutls debug ``` (Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [simple_bind_send] (0x0100): Executing simple bind as: uid=mof_user1,dc=example,dc=com gnutls[5]: REC[0x6ae7d0]: Preparing Packet Application Data(23) with length: 86 and min pad: 0 gnutls[9]: ENC[0x6ae7d0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 gnutls[11]: WRITE: enqueued 91 bytes for 0x64aec0. Total 91 bytes. gnutls[11]: WRITE FLUSH: 91 bytes in buffer. gnutls[11]: WRITE: wrote 91 bytes, 0 bytes left. gnutls[5]: REC[0x6ae7d0]: Sent Packet[2] Application Data(23) in epoch 0 and length: 91 (Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [simple_bind_send] (0x2000): ldap simple bind sent, msgid = 2 (Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [sdap_op_add] (0x2000): New operation 2 timeout 6 (Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0x696940], connected[1], ops[0x696a90], ldap[0x698cf0] (Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0x696940], connected[1], ops[0x696a90], ldap[0x698cf0] gnutls[10]: READ: Got 5 bytes from 0x64aec0 gnutls[10]: READ: read 5 bytes from 0x64aec0 gnutls[10]: RB: Have 0 bytes into buffer. Adding 5 bytes. gnutls[10]: RB: Requested 5 bytes gnutls[5]: REC[0x6ae7d0]: SSL 3.3 Handshake packet received. Epoch 0, length: 1124 gnutls[5]: REC[0x6ae7d0]: Expected Packet Application Data(23) gnutls[5]: REC[0x6ae7d0]: Received Packet Handshake(22) with length: 1124 gnutls[10]: READ: Got 1124 bytes from 0x64aec0 gnutls[10]: READ: read 1124 bytes from 0x64aec0 gnutls[10]: RB: Have 5 bytes into buffer. Adding 1124 bytes. gnutls[10]: RB: Requested 1129 bytes gnutls[5]: REC[0x6ae7d0]: Decrypted Packet[0] Handshake(22) with length: 1124 gnutls[3]: ASSERT: handshake.c[_gnutls_recv_hello_request]:3384 gnutls[3]: ASSERT: record.c[_gnutls_recv_in_buffers]:1323 gnutls[3]: ASSERT: record.c[_gnutls_recv_int]:1468 (Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x0040): ldap_result error: [Can't contact LDAP server] (Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [sdap_handle_release] (0x2000): Trace: sh[0x696940], connected[1], ops[0x696a90], ldap[0x698cf0], destructor_lock[0], release_memory[0] (Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [sdap_op_destructor] (0x1000): Abandoning operation 2 gnutls[5]: REC[0x6ae7d0]: Preparing Packet Application Data(23) with length: 8 and min pad: 0 gnutls[9]: ENC[0x6ae7d0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 gnutls[11]: WRITE: enqueued 13 bytes for 0x64aec0. Total 13 bytes. gnutls[11]: WRITE FLUSH: 13 bytes in buffer. gnutls[11]: WRITE: wrote 13 bytes, 0 bytes left. gnutls[5]: REC[0x6ae7d0]: Sent Packet[3] Application Data(23) in epoch 0 and length: 13 gnutls[11]: WRITE FLUSH: 0 bytes in buffer. gnutls[3]: ASSERT: buffers.c[_gnutls_io_write_flush]:694 gnutls[5]: REC: Sending Alert[1|0] - Close notify gnutls[5]: REC[0x6ae7d0]: Preparing Packet Alert(21) with length: 2 and min pad: 0 gnutls[9]: ENC[0x6ae7d0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 gnutls[11]: WRITE: enqueued 7 bytes for 0x64aec0. Total 7 bytes. gnutls[11]: WRITE FLUSH: 7 bytes in buffer. gnutls[11]: WRITE: wrote 7 bytes, 0 bytes left. gnutls[5]: REC[0x6ae7d0]: Sent Packet[4] Alert(21) in epoch 0 and length: 7 (Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [dp_req_done] (0x0400): DP Request [PAM Authenticate #5]: Request handler finished [0]: Success (Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [_dp_req_recv] (0x0400): DP Request [PAM Authenticate #5]: Receiving request data. (Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400): DP Request [PAM Authenticate #5]: Request removed. (Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400): Number of active DP request: 0 (Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [dp_method_enabled] (0x0400): Target selinux is not configured (Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [dp_pam_reply] (0x1000): DP Request [PAM Authenticate #5]: Sending result [4][LDAP] ``` """
See the full comment at https://github.com/SSSD/sssd/pull/67#issuecomment-256591142
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
nmav commented: """ Could you explain what is the interaction between sssd and gnutls? Do you pass the fd (which was set to non-blocking) or so? """
See the full comment at https://github.com/SSSD/sssd/pull/67#issuecomment-256611358
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
nmav commented: """ Could you explain what is the interaction between sssd and gnutls? Do you pass the fd (which was set to non-blocking) or so to gnutls? """
See the full comment at https://github.com/SSSD/sssd/pull/67#issuecomment-256611358
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
lslebodn commented: """
Could you explain what is the interaction between sssd and gnutls? Do you pass the fd (which was set to non-blocking) or so to gnutls?
There is not direct interaction/usage between sssd and gnutls. It's done indirectly via libldap 1. SOCK_STREAM socket is created by sssd 2. O_NONBLOCK is set on this socket 3. sssd creates connection to the ldap server (using connect syscall) 4. created socket descriptor is passed to the `ldap_init_fd` for initialisation of ldap handler which is used for any libldap operations. 5. If sssd is configured with ldap authentication then sssd tries to bind to the ldap server as user. Underneath, libldap will start_tls because we do not want to pass unencrypted password via network
Before sssd-1.14.0 we were unsetting O_NONBLOCK before 4th step.
BTW these 5 steps work well with sssd-1.14 if lildap is compiled with openssl or moznss """
See the full comment at https://github.com/SSSD/sssd/pull/67#issuecomment-256615534
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
nmav commented: """ I think from the above is clear that there must be some issue in the non-blocking support of libldap with gnutls, or that you are not using it properly. If you know you are using it properly and you know the offending calls, I could check them for their usage of gnutls and whether they are handling the non-blocking case (just post links to the offending code). """
See the full comment at https://github.com/SSSD/sssd/pull/67#issuecomment-256617499
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
lslebodn commented: """ On (27/10/16 02:03), Nikos Mavrogiannopoulos wrote:
I don't quite understand what the fix is about nor how it relates to gnutls. Is it about wrong handling of the client socket? To know whether the issue is on the gnutls server, I'll need more information from the server side (gnutls version, a run with GNUTLS_DEBUG_LEVEL set to 6 or more, and a capture of the session).
Actually, this is not related to openldap server. I tested debian client (libldap + gnutls) against rhel7 openldap server (libldap + nss). So gnutls is not involved on server side.
The version of gnutls on client side(debian testing) is 3.5.5-2.
I will try to get some GNUTLS log from client.
LS
"""
See the full comment at https://github.com/SSSD/sssd/pull/67#issuecomment-256680099
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
jhrozek commented: """ It looks like this patch has stalled a bit. @lslebodn I think it makes sense to merge it anyway, even if we continue discussing some possible additional changes to libldap...that can be done later. Accepting this patch would make sssd usable for Debian&family again. """
See the full comment at https://github.com/SSSD/sssd/pull/67#issuecomment-267285373
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
jhrozek commented: """ Please push this patch already :) """
See the full comment at https://github.com/SSSD/sssd/pull/67#issuecomment-272657236
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
Label: +Accepted
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
nmav commented: """ Is that issue related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849756 ? """
See the full comment at https://github.com/SSSD/sssd/pull/67#issuecomment-272789932
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
lslebodn commented: """
Is that issue related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849756 ?
I think that is just a side effect of this bug with openldap + gnutls """
See the full comment at https://github.com/SSSD/sssd/pull/67#issuecomment-272800457
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
lslebodn commented: """ master: * 31459a01486cfb2c04759bc998ff0c3ed19df81e
sssd-1-14: * 09d9394c2aea5ddc61d11c4771e806dfaa233ef7
"""
See the full comment at https://github.com/SSSD/sssd/pull/67#issuecomment-275087823
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
Label: +Pushed
URL: https://github.com/SSSD/sssd/pull/67 Author: lslebodn Title: #67: UTIL: Unset O_NONBLOCK for ldap connection Action: closed
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/67/head:pr67 git checkout pr67
sssd-devel@lists.fedorahosted.org
-
fidencio