OpenLDAP module fails to load
Hello everyone, I am the maintainer of the FreeRADIUS package for Fedora and RHEL. We are currently trying to fix this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1983063 Apparently, it appears since this OpenLDAP commit, related to the TLS connection start: https://git.openldap.org/openldap/openldap/-/commit/735e1ab14 If we build the OpenLDAP package without the LDAP_USE_NON_BLOCKING_TLS flag, the issue disappears, so it is probably related to the async connection. I've seen there has been some work on the async LDAP connection process, but I'm not entirely sure whether it is related, and it is only in v4: https://github.com/FreeRADIUS/freeradius-server/pull/4240 I'm wondering whether FreeRADIUS needs to adapt to these changes or the issue is entirely on the OpenLDAP side. What do you think? Thank you!
On Oct 8, 2021, at 5:25 AM, Antonio Torres <antorres@redhat.com> wrote:
If we build the OpenLDAP package without the LDAP_USE_NON_BLOCKING_TLS flag, the issue disappears, so it is probably related to the async connection. I've seen there has been some work on the async LDAP connection process, but I'm not entirely sure whether it is related, and it is only in v4: https://github.com/FreeRADIUS/freeradius-server/pull/4240
We're moving v4 to be completely async, but that's unrelated to the v3 code.
I'm wondering whether FreeRADIUS needs to adapt to these changes or the issue is entirely on the OpenLDAP side. What do you think?
The code in v3 uses a function rlm_ldap_bind() to bind to LDAP. That function takes a "retry" parameter. Most callers of the function pass a "retry" option. That causes the function to immediately retry the connection request. The main caller which *doesn't* to rebind is the mod_conn_create() function, which tries to create the initial connection. The fix might be as simple as changing the retry parameter in mod_conn_create() from "false" to "true". If that works, we can add it in. Alan DeKok.
On Fri, Oct 8, 2021 at 2:35 PM Alan DeKok <aland@deployingradius.com> wrote:
Most callers of the function pass a "retry" option. That causes the function to immediately retry the connection request. The main caller which *doesn't* to rebind is the mod_conn_create() function, which tries to create the initial connection.
The fix might be as simple as changing the retry parameter in mod_conn_create() from "false" to "true". If that works, we can add it in.
I tried that during my debug process. However it results in a segmentation fault, since apparently the pool for the instance is NULL. Segfaults in this line: https://github.com/FreeRADIUS/freeradius-server/blob/c6f15c7ee66dc0473ef45e7... On Fri, Oct 8, 2021 at 2:35 PM Alan DeKok <aland@deployingradius.com> wrote:
On Oct 8, 2021, at 5:25 AM, Antonio Torres <antorres@redhat.com> wrote:
If we build the OpenLDAP package without the LDAP_USE_NON_BLOCKING_TLS flag, the issue disappears, so it is probably related to the async connection. I've seen there has been some work on the async LDAP connection process, but I'm not entirely sure whether it is related, and it is only in v4: https://github.com/FreeRADIUS/freeradius-server/pull/4240
We're moving v4 to be completely async, but that's unrelated to the v3 code.
I'm wondering whether FreeRADIUS needs to adapt to these changes or the issue is entirely on the OpenLDAP side. What do you think?
The code in v3 uses a function rlm_ldap_bind() to bind to LDAP. That function takes a "retry" parameter.
Most callers of the function pass a "retry" option. That causes the function to immediately retry the connection request. The main caller which *doesn't* to rebind is the mod_conn_create() function, which tries to create the initial connection.
The fix might be as simple as changing the retry parameter in mod_conn_create() from "false" to "true". If that works, we can add it in.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Oct 8, 2021, at 8:45 AM, Antonio Torres <antorres@redhat.com> wrote:
I tried that during my debug process. However it results in a segmentation fault, since apparently the pool for the instance is NULL. Segfaults in this line: https://github.com/FreeRADIUS/freeradius-server/blob/c6f15c7ee66dc0473ef45e7...
Ah, yes. The pool isn't set up yet. The solution is more complex, then. What *should* happen is that the LDAP library returns a "partially open" connection. i.e. a connection which is partially bound, but which still needs to read/write more data. It looks like instead it returns *no* connection. Which puts FreeRADIUS into a bit of a problem. If every operation (a) doesn't return any handle, and (b) returns "retry", then there's simply no way to say "continue connecting on partially open handle". And nothing will ever work. The short term solution is to just set "start=0" in the "pool" configuration of the LDAP module. *And* also set the retry parameter to "true". Along with some other changes (attached), that might work. If that helps, I can push the patch over.
On Fri, Oct 8, 2021 at 3:00 PM Alan DeKok <aland@deployingradius.com> wrote:
The short term solution is to just set "start=0" in the "pool" configuration of the LDAP module. *And* also set the retry parameter to "true". Along with some other changes (attached), that might work.
That worked. I have created a PR with the changes: https://github.com/FreeRADIUS/freeradius-server/pull/4266 On Fri, Oct 8, 2021 at 3:00 PM Alan DeKok <aland@deployingradius.com> wrote:
On Oct 8, 2021, at 8:45 AM, Antonio Torres <antorres@redhat.com> wrote:
I tried that during my debug process. However it results in a segmentation fault, since apparently the pool for the instance is NULL. Segfaults in this line: https://github.com/FreeRADIUS/freeradius-server/blob/c6f15c7ee66dc0473ef45e7...
Ah, yes. The pool isn't set up yet. The solution is more complex, then.
What *should* happen is that the LDAP library returns a "partially open" connection. i.e. a connection which is partially bound, but which still needs to read/write more data. It looks like instead it returns *no* connection.
Which puts FreeRADIUS into a bit of a problem. If every operation (a) doesn't return any handle, and (b) returns "retry", then there's simply no way to say "continue connecting on partially open handle". And nothing will ever work.
The short term solution is to just set "start=0" in the "pool" configuration of the LDAP module. *And* also set the retry parameter to "true". Along with some other changes (attached), that might work.
If that helps, I can push the patch over.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (2)
-
Alan DeKok -
Antonio Torres