Bugzilla – Bug 2737
Gatekeeper AuthZ Callout producing SIGSEGV on deny response
Last modified: 2005-03-22 12:17:42
You need to log in before you can comment on or make changes to this bug.
When performing grid-map authorization via a call-out module we see the behavior that the gatekeeper fails quitely after the module has returned, if the return response was negative. The following is the GDB output: ----------------------- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 4882)] 0x402102d6 in globus_error_print_friendly (error=0x80c7b90) at globus_error_generic.c:884 884 if(module && module->friendly_error_func) (gdb) bt #0 0x402102d6 in globus_error_print_friendly (error=0x80c7b90) at globus_error_generic.c:884 #1 0x0804bdb1 in doit () at globus_gatekeeper.c:1436 --------------------------- In this case the deny/error response for the return value was initialized with: -------------------------------------- GLOBUS_GRIDMAP_CALLOUT_ERROR( result, GLOBUS_GRIDMAP_CALLOUT_LOOKUP_FAILED, ("Could not retrieve mapping for %s from identity mapping server\n", peer_name_buffer.value)); return result; ------------------------------------ Suspicition was that there is a problem with module activation
Created an attachment (id=522) [details] Patch that moves callout handle init to first call of function
I'll commit the changes once our CVS repo unfreezes after the 3.9.5 release.
Thank you Sam, I've adapted your path for gss-assist-3.10 which is what is used currently in VDT. It seems to work great. My patch file is at http://zuni.cs.vt.edu/privilege/osg-0/gss-assist-callout-fix.diff Changes applied to your patch version were - removed part of patch that doesn't apply to gss_assist - removed change to version number in pkgdata On our development version (older GT3.3 with gss-assist 3.8) more manual changes were necessary: - work around some commented out debugging code in gridmap.c (marked with JGW) - remove null initialization of a new mutex object