Bugzilla – Bug 892
GET_HOST_CERT_FILENAME and X509_USER_CERT, X509_USER_KEY settings
Last modified: 2008-08-11 15:16:10
You need to log in before you can comment on or make changes to this bug.
Hello, I am running GTK 2.2.3 on Linux RH7.3 (kernel 2.4.18-27.7.x.cern) and encountered the problem below and I would like to understand if it is due to misuse from my part or it is a feature. I was not able to find anything related on your previous bug reports; also, looking at the relevant code in version 2.2.4 it does not seem that it should behave differently, but of course I could be wrong. I have recently (January) introduced in my application the possibility to authenticate to a remore server using Globus certificates. Everything seemed to work fine until when I have decided to improve the flexibility of the service by allowing the user to choose on the fly the relevant certificates. I have done this making use of the environment variables X509_USER_CERT and X509_USER_KEY. But then I've suddendly got unwanted features; if the two variables are both set, even to the their default values, ie setenv X509_USER_CERT $HOME/.globus/usercert.pem setenv X509_USER_KEY $HOME/.globus/userkey.pem the program is unable to find valid proxies and requires always to reinitialize them. Luckly enough I was able to reproduce the problem with my test standalone program, and digging a bit inside the called functions I have found the place from where the problem originates: it is in the function globus_gsi_sysconfig_get_host_cert_filename_unix It seems that this function is always called, even if we are dealing with user certificates: this is not a problem by itself, since there is the way to distinguish between a good user and a good host certificate; but this check is not performed if both X509_USER_CERT and X509_USER_KEY are defined and point to valid cert and key PEM files. If I modify the logic of the function accordingly the problem disappears. But I am not sure that this is what one has to do. My worry is that I am doing something wrong in other places, though I am running out of ideas, especially for my standalone program, which is very essential. I would appreciate very much your opinion. Thanks in advance. Gerardo Ganis LCG/FZK
It is a sort of a feature. The page http://www.globus.org/security/config.html describes how credentials are acquired (look for Credential Acquisition Rules towards the bottom of the page). The problem is that we have overloaded the environment variables you are using so that they can be used for host/service credential acquisition as well as user credential acquisition. And since the host/service cert acquisition is tried before the proxy, your approach will run into the problem you describe. Given the above, is there any reason why you can't unset the variables before acquiring the proxy?
Dear Dr Meder, Probably I did not explain myself properly. First, I try to answer to your question: > is there any reason why you can't unset the variables before > acquiring the proxy? The fact is that within my application I may need to access two or more different remote accounts, and therefore to initialize different proxies using certificates and private key files both located in a different directory from the default one; the natural way to do this is (I believe) to change the proxy, usercert and userkey files setting properly the X509_USER_PROXY, X509_USER_CERT and X509_USER_KEY variables. Now, going back to the problem I have encountered, I am still convinced that this is not a feature; at least there is some inconsistency, because if you overload X509_USER_CERT only or X509_USER_KEY only everything works fine, the problem appearing only when you overload both at the same time ... Let me go into details. The validity of the host cert and key files is done inside this conditional scope (in function globus_gsi_sysconfig_get_host_cert_filename_unix, file globus_gsi_system_config.c): ... /* now check installed location for host cert */ if(!(*host_cert) || !(*host_key)) { globus_location = getenv("GLOBUS_LOCATION"); if(globus_location) { result = globus_i_gsi_sysconfig_create_cert_string( host_cert, & installed_host_cert, & status, "%s%s%s%s%s%s", globus_location, FILE_SEPERATOR, X509_INSTALLED_CERT_DIR, FILE_SEPERATOR, X509_HOST_PREFIX, X509_CERT_SUFFIX); if(result != GLOBUS_SUCCESS) { GLOBUS_GSI_SYSCONFIG_ERROR_CHAIN_RESULT( result, GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_CERT_STRING); goto done; } result = globus_i_gsi_sysconfig_create_key_string( host_key, & installed_host_key, & status, "%s%s%s%s%s%s", globus_location, FILE_SEPERATOR, X509_INSTALLED_CERT_DIR, FILE_SEPERATOR, X509_HOST_PREFIX, X509_KEY_SUFFIX); if(result != GLOBUS_SUCCESS) { GLOBUS_GSI_SYSCONFIG_ERROR_CHAIN_RESULT( result, GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING); goto done; } if((*host_cert) && !(*host_key)) { GLOBUS_GSI_SYSCONFIG_ERROR_RESULT( result, GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING, ("Host certificate is at: %s, but a host cert " "coult not be found at: %s", *host_cert, installed_host_key)); free(*host_cert); goto done; } if((*host_key) && !(*host_cert)) { GLOBUS_GSI_SYSCONFIG_ERROR_RESULT( result, GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING, ("Host key is at: %s, but a host certificate " "could not be found at: %s", *host_key, installed_host_cert)); free(*host_key); goto done; } } } ... The problem is that if both X509_USER_CERT and X509_USER_KEY are overloaded, both *host_cert and *host_key will be != NULL and the instructions within the scope will never be executed, while if at least one of the two variables is not overloaded the validity checks are executed. In my patched version I have separated the validity checks like this: /* now check validity of files found (if any) */ if( *host_cert ) { result = globus_i_gsi_sysconfig_create_cert_string( host_cert, & default_host_cert, & status, "%s%s%s%s", X509_DEFAULT_CERT_DIR, FILE_SEPERATOR, X509_HOST_PREFIX, X509_CERT_SUFFIX); if(result != GLOBUS_SUCCESS) { GLOBUS_GSI_SYSCONFIG_ERROR_CHAIN_RESULT( result, GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_CERT_STRING); goto done; } } if( *host_key ) { result = globus_i_gsi_sysconfig_create_key_string( host_key, & default_host_key, & status, "%s%s%s%s", X509_DEFAULT_CERT_DIR, FILE_SEPERATOR, X509_HOST_PREFIX, X509_KEY_SUFFIX); if(result != GLOBUS_SUCCESS) { GLOBUS_GSI_SYSCONFIG_ERROR_CHAIN_RESULT( result, GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING); goto done; } } /* now check default locations for valid filenames */ if(!(*host_cert) || !(*host_key)) { if((*host_cert) && !(*host_key)) { GLOBUS_GSI_SYSCONFIG_ERROR_RESULT( result, GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING, ("Host certificate is at: %s, but a host cert " "coult not be found at: %s", *host_cert, default_host_key)); free(*host_cert); goto done; } if((*host_key) && !(*host_cert)) { GLOBUS_GSI_SYSCONFIG_ERROR_RESULT( result, GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING, ("Host key is at: %s, but a host certificate " "could not be found at: %s", *host_key, default_host_cert)); free(*host_key); goto done; } } This solves perfectly my problem (I can initiate proxies for all the users I want without exiting my application) and I don't see which bad side effect this could have on the rest. I hope I have explained better myself this time. I attach my patched version of globus_gsi_system_config.c in case of need. With kind regards, Gerardo Ganis On Thu, 29 May 2003 bugzilla-daemon@mcs.anl.gov wrote: > http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=892 > > meder@mcs.anl.gov changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |RESOLVED > Resolution| |ANSWERED > > > > ------- Additional Comments From meder@mcs.anl.gov 2003-05-29 18:50 ------- > It is a sort of a feature. The page > > http://www.globus.org/security/config.html > > describes how credentials are acquired (look for Credential Acquisition Rules > towards the bottom of the page). The problem is that we have overloaded the > environment variables you are using so that they can be used for host/service > credential acquisition as well as user credential acquisition. And since the > host/service cert acquisition is tried before the proxy, your approach will run > into the problem you describe. > > Given the above, is there any reason why you can't unset the variables before > acquiring the proxy? > > > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. >
On Fri, 30 May 2003, bugzilla-daemon@mcs.anl.gov wrote: > http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=892 > > > > > > ------- Additional Comments From Gerardo.Ganis@cern.ch 2003-05-30 07:05 ------- > > > Dear Dr Meder, > > Probably I did not explain myself properly. > > First, I try to answer to your question: > > > is there any reason why you can't unset the variables before > > acquiring the proxy? > > The fact is that within my application I may need to access two or more > different remote accounts, and therefore to initialize different proxies > using certificates and private key files both located in a different > directory from the default one; the natural way to do this is (I believe) to > change the proxy, usercert and userkey files setting properly the X509_USER_PROXY, > X509_USER_CERT and X509_USER_KEY variables. Right, I still don't see the problem though. Why can't you do the following: setenv(X509_USER_CERT, "/first/usercert.pem", 1); setenv(X509_USER_KEY, "/first/userkey.pem", 1); load certificate/key unsetenv(X509_USER_CERT); unsetenv(X509_USER_KEY) create & load proxy setenv(X509_USER_CERT, "/second/usercert.pem", 1); setenv(X509_USER_KEY, "/second/userkey.pem", 1); load certificate/key unsetenv(X509_USER_CERT); unsetenv(X509_USER_KEY) create & load proxy etc. More comments below: > > Now, going back to the problem I have encountered, I am still convinced > that this is not a feature; at least there is some inconsistency, because > if you overload X509_USER_CERT only or X509_USER_KEY only everything works > fine, the problem appearing only when you overload both at the same time ... > > Let me go into details. > > The validity of the host cert and key files is done inside this conditional > scope (in function globus_gsi_sysconfig_get_host_cert_filename_unix, file > globus_gsi_system_config.c): > > > ... > > /* now check installed location for host cert */ > if(!(*host_cert) || !(*host_key)) Ok, this if statement is a little stupid (should really be something like if(!(*host_cert) && !(*host_key)) (that's what it was changed to in 2.4). > { > globus_location = getenv("GLOBUS_LOCATION"); > > if(globus_location) > { > result = globus_i_gsi_sysconfig_create_cert_string( > host_cert, > & installed_host_cert, > & status, > "%s%s%s%s%s%s", > globus_location, > FILE_SEPERATOR, > X509_INSTALLED_CERT_DIR, > FILE_SEPERATOR, > X509_HOST_PREFIX, > X509_CERT_SUFFIX); > if(result != GLOBUS_SUCCESS) > { > GLOBUS_GSI_SYSCONFIG_ERROR_CHAIN_RESULT( > result, > GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_CERT_STRING); > goto done; > } > > result = globus_i_gsi_sysconfig_create_key_string( > host_key, > & installed_host_key, > & status, > "%s%s%s%s%s%s", > globus_location, > FILE_SEPERATOR, > X509_INSTALLED_CERT_DIR, > FILE_SEPERATOR, > X509_HOST_PREFIX, > X509_KEY_SUFFIX); > if(result != GLOBUS_SUCCESS) > { > GLOBUS_GSI_SYSCONFIG_ERROR_CHAIN_RESULT( > result, > GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING); > goto done; > } > > if((*host_cert) && !(*host_key)) > { > GLOBUS_GSI_SYSCONFIG_ERROR_RESULT( > result, > GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING, > ("Host certificate is at: %s, but a host cert " > "coult not be found at: %s", > *host_cert, installed_host_key)); > free(*host_cert); > goto done; > } > > if((*host_key) && !(*host_cert)) > { > GLOBUS_GSI_SYSCONFIG_ERROR_RESULT( > result, > GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING, > ("Host key is at: %s, but a host certificate " > "could not be found at: %s", > *host_key, installed_host_cert)); > free(*host_key); > goto done; > } > } > } > > ... > > > The problem is that if both X509_USER_CERT and X509_USER_KEY are > overloaded, both *host_cert and *host_key will be != NULL and the > instructions within the scope will never be executed, while if > at least one of the two variables is not overloaded the validity checks > are executed. > > In my patched version I have separated the validity checks like this: > > /* now check validity of files found (if any) */ > if( *host_cert ) To be equivalent to the above this should be if( !*host_cert ) /Sam > { > result = globus_i_gsi_sysconfig_create_cert_string( > host_cert, > & default_host_cert, > & status, > "%s%s%s%s", > X509_DEFAULT_CERT_DIR, > FILE_SEPERATOR, > X509_HOST_PREFIX, > X509_CERT_SUFFIX); > if(result != GLOBUS_SUCCESS) > { > GLOBUS_GSI_SYSCONFIG_ERROR_CHAIN_RESULT( > result, > GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_CERT_STRING); > goto done; > } > } > if( *host_key ) > { > result = globus_i_gsi_sysconfig_create_key_string( > host_key, > & default_host_key, > & status, > "%s%s%s%s", > X509_DEFAULT_CERT_DIR, > FILE_SEPERATOR, > X509_HOST_PREFIX, > X509_KEY_SUFFIX); > if(result != GLOBUS_SUCCESS) > { > GLOBUS_GSI_SYSCONFIG_ERROR_CHAIN_RESULT( > result, > GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING); > goto done; > } > } > > /* now check default locations for valid filenames */ > if(!(*host_cert) || !(*host_key)) > { > if((*host_cert) && !(*host_key)) > { > GLOBUS_GSI_SYSCONFIG_ERROR_RESULT( > result, > GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING, > ("Host certificate is at: %s, but a host cert " > "coult not be found at: %s", > *host_cert, default_host_key)); > free(*host_cert); > goto done; > } > > if((*host_key) && !(*host_cert)) > { > GLOBUS_GSI_SYSCONFIG_ERROR_RESULT( > result, > GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING, > ("Host key is at: %s, but a host certificate " > "could not be found at: %s", > *host_key, default_host_cert)); > free(*host_key); > goto done; > } > } > > This solves perfectly my problem (I can initiate proxies for all the > users I want without exiting my application) and I don't see which > bad side effect this could have on the rest. > > I hope I have explained better myself this time. > > I attach my patched version of globus_gsi_system_config.c in case of need. > > With kind regards, > > Gerardo Ganis > > > > On Thu, 29 May 2003 bugzilla-daemon@mcs.anl.gov wrote: > > > http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=892 > > > > meder@mcs.anl.gov changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > Status|NEW |RESOLVED > > Resolution| |ANSWERED > > > > > > > > ------- Additional Comments From meder@mcs.anl.gov 2003-05-29 18:50 ------- > > It is a sort of a feature. The page > > > > http://www.globus.org/security/config.html > > > > describes how credentials are acquired (look for Credential Acquisition Rules > > towards the bottom of the page). The problem is that we have overloaded the > > environment variables you are using so that they can be used for host/service > > credential acquisition as well as user credential acquisition. And since the > > host/service cert acquisition is tried before the proxy, your approach will run > > into the problem you describe. > > > > Given the above, is there any reason why you can't unset the variables before > > acquiring the proxy? > > > > > > > > ------- You are receiving this mail because: ------- > > You reported the bug, or are watching the reporter. > > > > > > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. >
Hello, I may be totally wrong, but I don't believe the problem is solved with the version: On Fri, 30 May 2003 bugzilla-daemon@mcs.anl.gov wrote: > http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=892 > > > Right, I still don't see the problem though. Why can't you do the following: > > setenv(X509_USER_CERT, "/first/usercert.pem", 1); > setenv(X509_USER_KEY, "/first/userkey.pem", 1); > > load certificate/key > > unsetenv(X509_USER_CERT); > unsetenv(X509_USER_KEY) > > create & load proxy > > setenv(X509_USER_CERT, "/second/usercert.pem", 1); > setenv(X509_USER_KEY, "/second/userkey.pem", 1); > > load certificate/key > > unsetenv(X509_USER_CERT); > unsetenv(X509_USER_KEY) > > create & load proxy > > etc. That's exactly what I was doing but it does not work ... > > /* now check installed location for host cert */ > > if(!(*host_cert) || !(*host_key)) > > > Ok, this if statement is a little stupid (should really be something like > if(!(*host_cert) && !(*host_key)) (that's what it was changed to in 2.4). But this will not work either! I have just checked with version 2.4 ... Because the condition for this scope to be executed is that both variables ( X509_USER_CERT and X509_USER_KEY ) are not overloaded! If at least one of the two is overloaded (in the way you suggest above) the validity test is not performed, the functions assumes that these are *good host and key* files and then it fails ... The following may work: if( (*host_cert) || (*host_key) ) but then you may have problems when one is of the two is not defined ... I have not checked. I think that performing separate checks is more natural ... > > In my patched version I have separated the validity checks like this: > > > > /* now check validity of files found (if any) */ > > if( *host_cert ) > > To be equivalent to the above this should be if( !*host_cert ) I don't agree, because if you want to use the same variables for user and host certificates, in the function for host files you must check the validity of the certificate when the variable is overloaded, that is when *host_cert is TRUE ... The same holds for the key file. The patched version that I have sent to you may not be the most elegant, but it works in all possible combinations. The new version in 2.4 is not working at all, since it does not even allow to change one of the two files ... Of course it works with defaults, when you do not touch (overload) the two environment variables. Gerardo Ganis
Ok, I'll have to check into why my suggested solution is not working. Is the scenario I describe exactly what you want to do btw? Can I ask what function you are using to acquire credentials? gss_acquire_cred() or globus_gsi_cred_read()? /Sam
On Mon, 2 Jun 2003 bugzilla-daemon@mcs.anl.gov wrote: > http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=892 > > meder@mcs.anl.gov changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|RESOLVED |REOPENED > Resolution|ANSWERED | > > > > ------- Additional Comments From meder@mcs.anl.gov 2003-06-02 08:33 ------- > Ok, I'll have to check into why my suggested solution is not working. > Is the scenario I describe exactly what you want to do btw? Yes, I think you have understood what I would like to do and what you propose is exactly what I have tried first following the documentation ... > Can I ask what function you are using to acquire credentials? > gss_acquire_cred() or globus_gsi_cred_read()? I am calling globus_gss_assist_acquire_cred as suggested in http://www.globus.org/security/gss_assist.html Thanks for your reply. Gerardo
Created an attachment (id=223) [details] Small program reproducing the problem / patched globus_gsi_system_config.c As already stated, the problem mentioned in bug #892 is still present in GTK version 2.4.3 . The atteched program testCred.c (compiled as shown in testCred.Mk) allows to reproduce the problem. This is teh sequence of my actions and the corresponding results: 1) grid-proxy-init Your identity: /O=Grid/OU=GlobusTest/OU=simpleCA-arthux.cern.ch/OU=cern.ch/CN=ganis globus_gsi_cred_read_key: enter: keyfile:/home/ganis/.globus/userkey.pem Enter GRID pass phrase for this identity: Creating proxy ................................ Done Your proxy is valid until: Fri Oct 17 04:00:32 2003 2) testCred GSS: acquiring host credentials ... 3) Overload certificate and key files with defaults setenv X509_USER_KEY $HOME/.globus/userkey.pem setenv X509_USER_KEY $HOME/.globus/usercert.pem 4) testCred GSS: acquiring host credentials ... gss_assist_acquire_cred host: Error GSS Major Status: General failure GSS Minor Status Error Chain: acquire_cred.c:123: gss_acquire_cred: Error with GSI credential globus_i_gsi_gss_utils.c:1308: globus_i_gsi_gss_cred_read: Error with gss credential handle globus_gsi_credential.c:490: globus_gsi_cred_read: Error reading host credential globus_gsi_credential.c:1109: globus_gsi_cred_read_key: Error reading user credential: Can't read credential's private key from PEM OpenSSL Error: pem_lib.c:434: in library: PEM routines, function PEM_do_header: bad password read OpenSSL Error: pem_lib.c:666: in library: PEM routines, function PEM_read_bio: no start line Unsetting any of the two environment variable the program works again as it should. I have included again a patched version of globus_gsi_system_config.c, which is however not different from the one already sent (attachment #129 [details]). Thanks for your attention. Gerardo Ganis
Created an attachment (id=225) [details] Fixes bug that test prog shows
2.2.3 has a problem in the credential reading code where it does not clear the openssl error before checking whether the key is password protected. This has been fixed in later versions. The patch that does so is attached. With this patch your test program works fine. Let me know if you have anymore problems. /Sam
Hello, Sorry for the late reply. Yes, it works now. Thanks a lot for your help. Gerardo Ganis -- +--------------------------------------------------------------------------+ Gerardo GANIS HIK - ForschungZentrum Karlsruhe address CERN / EP-SFT , CH 1211 Geneve 23 room: 32-RC-017, tel / fax: +412276 76439 / 79425 e-mail gerardo.ganis@cern.ch +--------------------------------------------------------------------------+ On Thu, 23 Oct 2003 bugzilla-daemon@mcs.anl.gov wrote: > http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=892 > > meder@mcs.anl.gov changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|REOPENED |RESOLVED > Resolution| |FIXED > > > > ------- Additional Comments From meder@mcs.anl.gov 2003-10-23 17:30 ------- > 2.2.3 has a problem in the credential reading code where it does not clear the > openssl error before checking whether the key is password protected. This has > been fixed in later versions. The patch that does so is attached. With this > patch your test program works fine. Let me know if you have anymore problems. > > /Sam > > > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. >