Bug 4308 - globusrun-ws handles -self differently than java clients
: globusrun-ws handles -self differently than java clients
Status: NEW
: Java WS Core
globus_wsrf_core
: 4.0.1
: Macintosh All
: P3 normal
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2006-03-23 16:13 by
Modified: 2007-09-12 16:47 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2006-03-23 16:13:57
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
[nothing]
$ grid-cert-info -file ~/.globus/hostcert.pem -subject
/DC=org/DC=doegrids/OU=Services/CN=host/grandcentral.cs.wisc.edu

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
...
 <ns2:ReferenceProperties xsi:type="ns2:ReferencePropertiesType">
  <ns1:CounterKey>9787710</ns1:CounterKey>
 </ns2:ReferenceProperties>

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.
 :-)
------- Comment #2 From 2006-03-23 16:27:49 -------
Okay - so does Java's behavior need to change?
------- Comment #3 From 2006-10-02 17:49:07 -------
I'm reassigning this to Jarek since Charles' question was targeted to him
AFAICT.
------- Comment #4 From 2007-09-12 16:47:37 -------
Reassigning to current wsrf developer to close/fix as appropriate

File this under "differences between C and java GSI".