On Mon, Jun 22, 2015 at 4:01 AM, Isaac Boukris <iboukris@gmail.com> wrote:
On Mon, Jun 22, 2015 at 3:52 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 21 Jun 2015, at 20:04, Isaac Boukris <iboukris@gmail.com> wrote:
On Mon, Jun 22, 2015 at 2:39 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Not really correct, but does give a clue to what might be going on. With your patch status wouldn't get set on the final round of SASL auth, so rlm_ldap_sasl_interactive would return the wrong ldap_rcode_t value.
Admittedly, I am not familiar enough with ldap library to be confident about my patch. It was based on gdb'ing both 'ldapsearch' and 'radiusd' and comparing the library calls as mentioned.
Sure.
rlm_ldap_result should be used to get the result via ldap_result, and check it for errors with ldap_parse_result. I can see that possibly ldap_parse_result is giving bad return codes, which is causing the loop to terminate.
Note that this is what 'ldapsearch' seem to be doing, it breaks from the loop before calling 'ldap_result()' once we aren't in 'progress', see: https://github.com/osstech-jp/openldap/blob/wiredtiger/clients/tools/common....
OK that helps.
So my guess is that ldap_result will indicate that the bind was successful before ldap_sasl_interactive_bind indicates tells us that, and that on the final loop ldap_sasl_interactive_bind doesn't actually send anything to the server, it just indicates that the previous operation was successful.
Yea, that what it looks like, I see on the wire that the server sent 'success' but ldap_sasl_interactive_bind still returns LDAP_SASL_BIND_IN_PROGRESS. Perhaps it just want to be called again in order to install the security layers (not to communicate with the server).
Ah possibly.
I tried to read some doc, it isn't clear but it could match the behaviour we see.
Slightly odd that it wouldn't set some kind of NULL/noop msgid that would indicate that, I guess that's a bug (or 'feature') of libldap.
I've fudged rlm_ldap_result to take a -1 msgid, which causes it to skip attempting to retrieve the result, and just do error processing using the handle.
I think that should fix everything.
Not yet :( I now get (limiting 'ssf' doesn't make a diff):
rlm_ldap (ldap): Connecting to ldap://ms.frenche.cp:389 rlm_ldap (ldap): Starting SASL mech(s): GSSAPI SASL/GSSAPI authentication started SASL username: anna@FRENCHE.CP SASL SSF: 56 SASL data security layer installed. radiusd: error.c:255: ldap_parse_result: Assertion `r != ((void *)0)' failed. Aborted (core dumped)
Let me know if you want the back-trace.
Nah I see the problem.
Thanks for working with me on this.
No problem. Should work now (hopefully).
One more to go :)
rlm_ldap (ldap): Connecting to ldap://ms.frenche.cp:389 rlm_ldap (ldap): Starting SASL mech(s): GSSAPI SASL/GSSAPI authentication started SASL username: anna@FRENCHE.CP SASL SSF: 56 SASL data security layer installed.
Program received signal SIGSEGV, Segmentation fault. 0xb7773114 in rlm_ldap_result (inst=0x8277490, conn=0x82a23b0, msgid=-1, dn=0xb777b564 "", result=0x0, error=0xbffff2fc, extra=0xbffff2f8) at src/modules/rlm_ldap/ldap.c:480 480 *result = NULL; (gdb) bt #0 0xb7773114 in rlm_ldap_result (inst=0x8277490, conn=0x82a23b0, msgid=-1, dn=0xb777b564 "", result=0x0, error=0xbffff2fc, extra=0xbffff2f8) at src/modules/rlm_ldap/ldap.c:480 #1 0xb77789e4 in rlm_ldap_sasl_interactive (inst=0x8277490, request=0x0, conn=0x82a23b0, identity=0xb777b564 "", password=0x0, sasl=0x82774ac, error=0xbffff2fc, extra=0xbffff2f8) at src/modules/rlm_ldap/sasl.c:142 #2 0xb77736a0 in rlm_ldap_bind (inst=0x8277490, request=0x0, pconn=0xbffff350, dn=0xb777b564 "", password=0x0, sasl=0x82774ac, retry=false) at src/modules/rlm_ldap/ldap.c:717
Perhaps I could add dbg prints.
BTW the ldapsearch example seem to verify the returned value from rlm_ldap_sasl_interactive to be eq to LDAP_SUCCESS in order to conclude success.