Though the bug references just one commit, it was part of a larger set
of commits:
http://www.globus.org/mail_archive/csec-commit/2007/06/threads.html
You'll need all three - the first one just adds the constant, but the
next two are what actually pass the constant into the openssl commands
to set the verify depth.
Charles
On Jul 31, 2008, at 11:24 AM, Neha Sharma wrote:
Thanks Charles.
Looks like I should be able to test this fix by defining
#define GLOBUS_GSI_CALLBACK_VERIFY_DEPTH 100
in the globus_gsi_callback_constants.h file
and rebuilding globus
I will try it out and let you know how it goes..
-Neha
On Jul 31, 2008, at 10:26 AM, Charles Bacon wrote:
Openssl comes with a default "maximum depth" of a PKI chain it
supports. That includes the CA and RA (if applicable). I suspect
you might be hitting GT4.0.x's depth limit of 9. If you're using a
CA+RA+Usercert+5 proxy, you might not be allowed to submit with
delegation anymore because the delegation would take you to the
depth limit.
It's a compiled-in limit that you can change. I believe we had a
bug open about the max depth ... yep, it's http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=4994
. It should be fixed in 4.2 to be 100 instead. You can probably
take that patch back to 4.0.x if you need the limit increased there
too.
Charles
On Jul 31, 2008, at 9:52 AM, Neha Sharma wrote:
Hi All
I am wondering if someone can provide me with some information
about the Globus function "globus_gss_assist_init_sec_context"
We have an authorization service and this globus function is used
for performing handshake between the service and the client.
We observed that as long as the proxy is delegated up to 4 times,
so that the DN is of form :
subject : /DC=gov/DC=fnal/O=Fermilab/OU=People/CN=Neha Sharma/
CN=UID:neha
or
subject : /DC=gov/DC=fnal/O=Fermilab/OU=People/CN=Neha Sharma/
CN=UID:neha/CN=proxy
or
subject : /DC=gov/DC=fnal/O=Fermilab/OU=People/CN=Neha Sharma/
CN=UID:neha/CN=proxy/CN=proxy
or
subject : /DC=gov/DC=fnal/O=Fermilab/OU=People/CN=Neha Sharma/
CN=UID:neha/CN=proxy/CN=proxy/CN=proxy
or
subject : /DC=gov/DC=fnal/O=Fermilab/OU=People/CN=Neha Sharma/
CN=UID:neha/CN=proxy/CN=proxy/CN=proxy/CN=proxy
everything works fine.
However, if it is delegated 5th time and above, so that the DN in
the proxy now has an extra "CN=proxy" , the client hangs on the
handshake.
(The DN looks like:
subject : /DC=gov/DC=fnal/O=Fermilab/OU=People/CN=Neha Sharma/
CN=UID:neha/CN=proxy/CN=proxy/CN=proxy/CN=proxy/CN=proxy)
The complete handshake function that is being used is below.
As you can see, all it does is invoke the globus function
"lobus_gss_assist_init_sec_context"
So, I am wondering if there is some kind of limitation in this
globus function, such as maximum length of user proxy or DN
int handshake(gss_cred_id_t credential_handle){
OM_uint32 ret_flags=0;
major_status =
globus_gss_assist_init_sec_context(&minor_status,
credential_handle,
&global_context_handle,
"GSI-NO-
TARGET",
//
GSS_C_DELEG_FLAG|GSS_C_MUTUAL_FLAG,
GSS_C_MUTUAL_FLAG,
&ret_flags,
&token_status,
globus_gss_assist_token_get_fd,
(void *)
socket_in_out_file,
globus_gss_assist_token_send_fd,
(void *)
socket_in_out_file);
if(major_status != GSS_S_COMPLETE){
logerr("Handshake Failed... major_status !=
GSS_S_COMPLETE");
return(GSS_FAILED_HANDSHAKE);
}
return(GSS_SUCCESS);
}
Thanks
-Neha