Bugzilla – Bug 4308
globusrun-ws handles -self differently than java clients
Last modified: 2007-09-12 16:47:37
You need to
before you can comment on or make changes to this bug.
This is unlikely to hit many users, but I just bumped into this today. I'm on
a machine which doesn't have anything in /etc/grid-security. I have a usercert
in ~/.globus, have created a proxy, but also (oddly) have a hostcert.pem and
hostkey.pem in ~/.globus too.
Here's how globusrun-ws behaves:
If I don't say -self:
$ bin/globusrun-ws -submit -c /bin/date
globus_gsi_gssapi: Authorization denied: The name of the remote host (Charles
Bacon 332900), and the expected name for the remote host (bacon.local) do not
match. This happens when the name in the host certificate does not match the
information obtained from DNS and is often a DNS configuration problem.
Okay, that makes sense, my laptop is named "bacon.local". If I do say -self:
$ bin/globusrun-ws -submit -self -c /bin/date
globus_gsi_gssapi: Authorization denied: The name of the remote entity
(/DC=org/DC=doegrids/OU=People/CN=Charles Bacon 332900), and the expected name
for the remote entity
(/DC=org/DC=doegrids/OU=Services/CN=host/grandcentral.cs.wisc.edu) do not match
Er, what? Where did the expected name come from?
$ grid-proxy-info -identity
/DC=org/DC=doegrids/OU=People/CN=Charles Bacon 332900
$ env | grep X509
$ grid-cert-info -file ~/.globus/hostcert.pem -subject
Okay, that's where it's getting it from, but I'm surprised it's looking there.
Let's check if the counter-client behaves the same way:
$ bin/counter-create -s
https://192.168.1.120:8443/wsrf/services/SecureCounterService -m conv
org.globus.common.ChainedIOException: Authentication failed [Caused by:
Operation unauthorized (Mechanism level: Authorization failed. Expected
"/CN=host/192.168.1.120" target but received
"/DC=org/DC=doegrids/OU=People/CN=Charles Bacon 332900")]
Right, okay. (although I dislike the difference between the IP expected by
java and the name expected by C). So let's give it a -z self:
$ bin/counter-create -s
https://192.168.1.120:8443/wsrf/services/SecureCounterService -z self -m conv
So that worked okay. We should figure out where the discrepancy comes from,
which behavior is expected, then fix the one that's working differently.
Workaround: Don't keep a hostcert in ~/.globus while using globusrun-ws -self.
Okay - so does Java's behavior need to change?
I'm reassigning this to Jarek since Charles' question was targeted to him
Reassigning to current wsrf developer to close/fix as appropriate
File this under "differences between C and java GSI".