Re: 1.1.2 is broken if you have closefrom()
On June 8, 2006 6:02:44 PM -0400 Alan DeKok <aland@nitros9.org> wrote:
Frank Cusack <fcusack@fcusack.com> wrote: The libltdl retards would allocate a data structure, partially fill it in, and then RETURN IT to the caller if ltdl_open() didn't work. Since ltdl_open() is documented as returning PTR on success and NULL on fail, it would look like the dlopen succeeded. The code would then call ltdl_sym(), using the previous bullshit structure, and the retarded ltdl_sym() code would de-reference a NULL pointer. It doesn't need to check, apparently, because that field is supposed to be initialized if ltdl_open() worked.
Your patch is actually in lt_dlopenext(), not lt_dlopen(). On inspection, I don't see a code path that leaves handle non-NULL on an error return. I'm also unable to reproduce the problem, and none of the bugs referencing this problem has an adequate description. Can you give me a formula to demonstrate this problem? I don't have mysql, which a lot of the cases seem to revolve around. -frank
Frank Cusack <fcusack@fcusack.com> wrote:
On inspection, I don't see a code path that leaves handle non-NULL on an error return. I'm also unable to reproduce the problem, and none of the bugs referencing this problem has an adequate description.
After I patched the existing libltdl, it's fine. Before, it wasn't.
Can you give me a formula to demonstrate this problem? I don't have mysql, which a lot of the cases seem to revolve around.
install libbar into /opt/lib/ ensure /opt/lib isn't in ldconfig, or LD_LIBRARY_PATH build FreeRADIUS with LDFLAGS=-L/opt/lib install rlm_foo into /usr/local/lib/ rlm_foo -> libbar ensure radiusd.conf, libdir = /usr/local/lib ldd rlm_foo should return error running freeradius should link rlm_foo, fail to link libbar, and return a partial ltdl_handle*. It's pretty easy to reproduce if you put libraries into a place where your dynamic linker can't find them. Alan DeKok.
On June 8, 2006 8:21:58 PM -0400 Alan DeKok <aland@nitros9.org> wrote:
Frank Cusack <fcusack@fcusack.com> wrote: It's pretty easy to reproduce if you put libraries into a place where your dynamic linker can't find them.
I just get an error message. Here's an example with rlm_eap_tls. I moved libcrypto out of the way. ... rlm_eap: Loaded and initialized type md5 rlm_eap: Loaded and initialized type leap gtc: challenge = "Password: " gtc: auth_type = "PAP" rlm_eap: Loaded and initialized type gtc rlm_eap: Failed to link EAP-Type/tls: ld.so.1: radiusd: fatal: libcrypto.so.0.9.8: open failed: No such file or directory radiusd.conf[10]: eap: Module instantiation failed. radiusd.conf[1919] Unknown module "eap". radiusd.conf[1866] Failed to parse authenticate section. -frank
On June 8, 2006 5:18:55 PM -0700 Frank Cusack <fcusack@fcusack.com> wrote:
On June 8, 2006 6:02:44 PM -0400 Alan DeKok <aland@nitros9.org> wrote:
Frank Cusack <fcusack@fcusack.com> wrote: On inspection, I don't see a code path that leaves handle non-NULL on an error return. I'm also unable to reproduce the problem, and none of the bugs referencing this problem has an adequate description.
And on even further inspection, I don't see how the gdb data in bug #98 could be generated from ltdl.c. Besides the fact that (in my possibly incorrect reading) handle is always set to NULL on error return, handle->next and handle->info.refcount aren't set until try_dlopen() is going to return success. So I see the problem (handle is invalid) but I don't see how handle could have possibly come out from lt_dlopenext() that way. It seems extremely unlikely that FR would munge the handle that badly, so my next best guess is that the problem was reported under a different ltdl.c than the one you actually patched. I'll investigate that path but in the meantime if anyone can describe a test case that would be good. -frank
Frank Cusack <fcusack@fcusack.com> wrote:
And on even further inspection, I don't see how the gdb data in bug #98 could be generated from ltdl.c. Besides the fact that (in my possibly incorrect reading) handle is always set to NULL on error return,
It's not... All I know is I managed to reproduce it reliably on my desktop, hence the fix. Alan DeKok.
On June 8, 2006 8:43:05 PM -0400 Alan DeKok <aland@nitros9.org> wrote:
All I know is I managed to reproduce it reliably on my desktop, hence the fix.
OK, I've been all over it and tried lots of configs and can't see this problem. Since I spent a bunch of time on this libtool/libltdl stuff (which is more frustrating than the typical problem), I'm loathe to have a patched ltdl.c, even if it's a minor patch. I can't convince you to try and reproduce it again, can I? -frank
Frank Cusack <fcusack@fcusack.com> wrote:
Since I spent a bunch of time on this libtool/libltdl stuff (which is more frustrating than the typical problem), I'm loathe to have a patched ltdl.c, even if it's a minor patch. I can't convince you to try and reproduce it again, can I?
Send me a patch... I love pain. No, wait, I love *sleep*. Alan DeKok.
On June 8, 2006 11:43:39 PM -0400 Alan DeKok <aland@nitros9.org> wrote:
Frank Cusack <fcusack@fcusack.com> wrote:
Since I spent a bunch of time on this libtool/libltdl stuff (which is more frustrating than the typical problem), I'm loathe to have a patched ltdl.c, even if it's a minor patch. I can't convince you to try and reproduce it again, can I?
Send me a patch... I love pain.
No, wait, I love *sleep*.
Ha! Just comment out the two lines added in 1.7. -frank
On June 8, 2006 11:43:39 PM -0400 Alan DeKok <aland@nitros9.org> wrote:
Frank Cusack <fcusack@fcusack.com> wrote:
Since I spent a bunch of time on this libtool/libltdl stuff (which is more frustrating than the typical problem), I'm loathe to have a patched ltdl.c, even if it's a minor patch. I can't convince you to try and reproduce it again, can I?
Send me a patch... I love pain.
Dunno if you didn't find time, or weren't able to reproduce it, but I found two similar reports on Google, so while I can't see the bug I do agree it's there (although quite rare). I would still like to understand the problem, so if you're able to get to this, great. But anyway, it looks easy to address in freeradius (as opposed to ltdl.c) so I'm going to try that. It's just a bit iffy since I can't actually reproduce the bug, but I figure, FR can't run under this condition anyway, the bug is just that it segfault's instead of reporting a useful error. Let me know what you think. -frank
Frank Cusack <fcusack@fcusack.com> wrote:
Dunno if you didn't find time, or weren't able to reproduce it
I couldn't bear the though of fighting with that crap again. Look at the code, it does the following: ... strcat (tmp, archive_ext); errors = try_dlopen (&handle, tmp); if (errors) return 0; /* If we found FILENAME, stop searching -- whether we were able to load the file as a module or not. If the file exists but loading failed, it is better to return an error message here than to report FILE_NOT_FOUND when the alternatives (foo.so etc) are not in the module search path. */ if (handle || ((errors > 0) && !file_not_found ())) { LT_DLFREE (tmp); return handle; } ... Note that if (errors > 0) AND the file was found, it returns the handle. i.e. It finds the CURRENT library, but not one that the current library needs. The idea of returning the handle if (errors > 0) is something that is mind-blowingly retarded.
But anyway, it looks easy to address in freeradius (as opposed to ltdl.c) so I'm going to try that.
I don't see how. The problem is that the handle is returned, but is NOT completely populated. So ltdl_sym() de-references a NULL entry in the handle, and dies. Since the handle structure is opaque, it's impossible for FreeRADIUS to know if the returned handle is OK, is is broken. So I have no idea how you would handle this in FreeRADIUS.
It's just a bit iffy since I can't actually reproduce the bug, but I figure, FR can't run under this condition anyway, the bug is just that it segfault's instead of reporting a useful error.
ltdl is helpful here, too. It doesn't keep track of the dependencies when it's reporting an error. So if you have rlm_sql_mysql, but not libmysqlclient, it complains that it can't find rlm_sql_mysql. See the list archives for multipl WTF questions from users. Alan DeKok.
participants (2)
-
Alan DeKok -
Frank Cusack