Bugzilla – Bug 5468
Creating and signing a hostcert with a non fully qualified hostname behaves odd
Last modified: 2008-08-11 15:51:53
You need to log in before you can comment on or make changes to this bug.
(GT version: 4.0.5) Creating a hostcert request for a non fully qualified hostname gives a sentence that the hostname is not fully qualified but does not abort regardless what i enter although it says that it's aborting. So if one does not look closely everything looks fine. Signing this hostcert request however fails. (Signing a hostcert request with a FQDN hostname works fine). I guess the correct behavior would be to really abort or to give a stronger warning. We ran into that on lucky0 of the lucky cluster in MCS. The command hostname here returns only lucky0, so calling "grid-cert-request -host `hostname`" as mentioned in the Quickstart guide causes this problem. Here's what happens, reproduced on my laptop: Create the hostcert request: ############################ lappi2:/etc/grid-security root# grid-cert-request -host lappi2 The hostname lappi2 does not appear to be fully qualified. Do you wish to continue? [n] Aborting Generating a 1024 bit RSA private key ...++++++ ...................................................................................++++++ writing new private key to '/etc/grid-security/hostkey.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Level 0 Organization [Grid]:Level 0 Organizational Unit [GlobusTest]:Level 1 Organizational Unit [simpleCA-lappi2.local]:Name (e.g., John M. Smith) []: A private host key and a certificate request has been generated with the subject: /O=Grid/OU=GlobusTest/OU=simpleCA-lappi2.local ---------------------------------------------------------- The private key is stored in /etc/grid-security/hostkey.pem The request is stored in /etc/grid-security/hostcert_request.pem Please e-mail the request to the Globus Simple CA feller@mcs.anl.gov You may use a command similar to the following: cat /etc/grid-security/hostcert_request.pem | mail feller@mcs.anl.gov Only use the above if this machine can send AND receive e-mail. if not, please mail using some other method. Your certificate will be mailed to you within two working days. If you receive no response, contact Globus Simple CA at feller@mcs.anl.gov Sign the hostcert request: ########################## lappi2:~ martinfeller$ grid-ca-sign \ -in /etc/grid-security/hostcert_request.pem \ -out hostcert.pem To sign the request please enter the password for the CA key: ERROR: Failed to find signed cert in CA cert store with subject: /O=Grid/OU=GlobusTest/OU=simpleCA-lappi2.local
But when you choose "y" for "continue?" it works right? Works here. I'm seeing the same thing you do when I choose "n", it sounds like the only problem here is that it should abort when "n" is chosen for continue. This is clearly what is intended in the code but it is not happening because the get_host_CN() function is running in a subshell so the call to "exit" there will not do the intended thing. Attachments are disabled so inlining... ---------------------------- This demonstrates the issue: ---------------------------- #!/bin/sh function afunc() { echo "hello" exit 1 } NOTEXITING=`afunc` echo "reachable" afunc echo "unreachable" --------------------- This fixes the issue: --------------------- --- grid-cert-request.orig 2007-08-01 17:15:29.000000000 -0500 +++ grid-cert-request 2007-08-01 17:17:48.000000000 -0500 @@ -591,7 +591,7 @@ *) ${GLOBUS_SH_ECHO-echo} "Aborting" 1>&2 - exit 1 + return 1 ;; esac fi @@ -600,6 +600,7 @@ fi echo ${_common_name} + return 0 } @@ -817,6 +818,9 @@ COMMON_NAME="`get_user_CN`" else COMMON_NAME="`get_host_CN`" + if [ $? -ne 0 ]; then + exit 1 + fi fi # do clean up on abort
(In reply to comment #1) > But when you choose "y" for "continue?" it works right? Works here. That works for me too.
Tim: Your patch works fine for me. Will/Can you commit it?
Committed to HEAD, but this may constitute an interface change in some people's eyes with respect to globus_4_0_branch (even if it is a positive one). For example someone may be running expect style wrappers around grid-cert-request... ?
hm, if backwards compatibility means keeping bugs then i would think it's too strict. Although this is not a big bug here. So I don't mind, i guess some people think more strict about BC than me.
I'd recommend sticking this in the 4.0 branch as well.
Commited to globus_4_0_branch as well