segfault calling rc_auth()
I have an ldap password plugin which calls rc_auth() to authenticate the user/pass combination with a freeradius server. I've used a plugin template from openLDAP and the code from radexample.c (1.1.6 on ubuntu 14.04) for the radius bits. I'm getting segfaults in libc sometimes in kernel.log and not sure what's causing the problem: traps: slapd[5181] general protection ip:7fa35a699c7f sp:7fa353664f90 error:0 in libc-2.19.so[7fa35a602000+1bb000] I have the code on pastebin to help clarify: line 126 (http://pastebin.com/NNzeetz5). Does this seem like an issue in the 1.1.6 freeradiusclient library somehow, or am I doing something boneheaded? Not sure at this point where to start looking for the problem. dmesg only shows the segfault entry and /var/log/freeradius/radius.log says "ldap_search() failed: LDAP connection lost.". The output in debug mode for the ldap server simply terminates as the segfault takes out slapd. Thanks for any help!
On Feb 2, 2016, at 3:46 PM, dev <devuan.2@gmail.com> wrote:
I have an ldap password plugin which calls rc_auth() to authenticate the user/pass combination with a freeradius server. I've used a plugin template from openLDAP and the code from radexample.c (1.1.6 on ubuntu 14.04) for the radius bits.
I'm getting segfaults in libc sometimes in kernel.log and not sure what's causing the problem: traps: slapd[5181] general protection ip:7fa35a699c7f sp:7fa353664f90 error:0 in libc-2.19.so[7fa35a602000+1bb000]
It's quite possibly a bug. Please try the code from github: https://github.com/FreeRADIUS/freeradius-client It has a number of fixes which may help.
I have the code on pastebin to help clarify: line 126 (http://pastebin.com/NNzeetz5).
Does this seem like an issue in the 1.1.6 freeradiusclient library somehow, or am I doing something boneheaded? Not sure at this point where to start looking for the problem. dmesg only shows the segfault entry and /var/log/freeradius/radius.log says "ldap_search() failed: LDAP connection lost.". The output in debug mode for the ldap server simply terminates as the segfault takes out slapd.
Thanks for any help! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 02/02/2016 02:46 PM, dev wrote:
I have the code on pastebin to help clarify: line 126 (http://pastebin.com/NNzeetz5).
PS: ignore line 87 in the paste. I was testing execl() to radtest and should have been removed from the paste.
On 02-02-16 21:46, dev wrote:
I have an ldap password plugin which calls rc_auth() to authenticate the user/pass combination with a freeradius server. I've used a plugin template from openLDAP and the code from radexample.c (1.1.6 on ubuntu 14.04) for the radius bits.
I'm getting segfaults in libc sometimes in kernel.log and not sure what's causing the problem: traps: slapd[5181] general protection ip:7fa35a699c7f sp:7fa353664f90 error:0 in libc-2.19.so[7fa35a602000+1bb000]
I have the code on pastebin to help clarify: line 126 (http://pastebin.com/NNzeetz5).
Does this seem like an issue in the 1.1.6 freeradiusclient library somehow, or am I doing something boneheaded? Not sure at this point where to start looking for the problem. dmesg only shows the segfault entry and /var/log/freeradius/radius.log says "ldap_search() failed: LDAP connection lost.". The output in debug mode for the ldap server simply terminates as the segfault takes out slapd.
It's probably the problem reported at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732052. If you just add a radius_deadtime option to the config the bug may disappear. -- Herwin Weststrate
On 02/03/2016 03:57 AM, Herwin Weststrate wrote:
It's probably the problem reported at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732052. If you just add a radius_deadtime option to the config the bug may disappear.
Thank you. I came across that bug report too. Tried both "0" and "1" for radius_deadtime but it made no difference in my case. I've cloned the code from github and built it using: ./configure --prefix=/usr/local/freeradius-client-git seems to be a problem with read_rc_config() now. It's returning NULL. strace shows radexample doing this: open("/usr/local/freeradius-client-git/etc/radiusclient/radiusclient.conf", O_RDONLY) = 3 That file does exist and is a copy of my production radiusclient.conf. What could be the problem here?
On 03-02-16 15:16, dev wrote:
Thank you. I came across that bug report too. Tried both "0" and "1" for radius_deadtime but it made no difference in my case.
I've cloned the code from github and built it using: ./configure --prefix=/usr/local/freeradius-client-git
seems to be a problem with read_rc_config() now. It's returning NULL.
rc_read_config, I assume. read_rc_config does not occur in the source.
strace shows radexample doing this: open("/usr/local/freeradius-client-git/etc/radiusclient/radiusclient.conf", O_RDONLY) = 3
That file does exist and is a copy of my production radiusclient.conf.
Yes, that file exists and is opened. The return value here (= 3) is the file descriptor returned by the open syscall.
What could be the problem here?
There are a number of reasons why rc_read_config may return NULL. Most of the add a logmessage. Otherwise, use something like gdb to step through the program, this will give more useful information than strace. -- Herwin Weststrate
On 02/03/2016 08:31 AM, Herwin Weststrate wrote:
rc_read_config, I assume. read_rc_config does not occur in the source.
Yes, my mistake. rc_read_config()
There are a number of reasons why rc_read_config may return NULL. Most of the add a logmessage. Otherwise, use something like gdb to step through the program, this will give more useful information than strace.
Thanks again. Checked syslog as you suggested and seems to be a leftover "seqfile" setting in my config. Commented it out and it's fixed: Feb 3 08:15:31 ldap1 radexample[14828]: /usr/local/freeradius-client-git/etc/radiusclient/radiusclient.conf: line 58: unrecognized keyword: seqfile It appears that the git version of freeradius-client does not exhibit the segfault behaviour I was seeing with the 1.1.6 Ubuntu package :) It will take further testing, but I could usually reproduce the issue within 10 logins or so. So far so good! Thanks again.
participants (3)
-
Alan DeKok -
dev -
Herwin Weststrate