Bug 3928 - IPv6 addresses in reverse lookups - fix or faq?
: IPv6 addresses in reverse lookups - fix or faq?
Status: NEW
: Java WS Security
Authentication
: unspecified
: PC Linux
: P3 normal
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-11-19 18:25 by
Modified: 2006-11-06 18:06 (History)


Attachments


Note

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


Description From 2005-11-19 18:25:59
Submitting job...Done.
Job ID: uuid:929fff7e-5947-11da-b5ea-00b0d0193d7d
Termination time: 11/20/2005 21:58 GMT
globusrun-ws: globus_service_engine_module: Session failed to start
globus_xio_gsi: The peer authenticated as
/O=Grid/OU=GlobusTest/OU=simpleCA-r11.uniandes.edu.co/CN=host/ubuntu2.uniandes.edu.co.
Expected the peer to authenticate as /CN=host/::ffff:192.168.0.11


I have seen this problem on the discuss list a couple of times now. It is
obviously a dns problem, but I wonder if we could do something to help out.

Some Linux distros set up IPv6 addresses automatically on network interfaces,
even if the user has only configured it with a IPv4 address. I don't think there
is an easy fix for this, but it would be nice to have a faq entry to point
people to. This comes back to what we were talking about at the security phone
call last week. I can not find a good place to add this. The closest is PreWS
Credential Errors section

http://www.globus.org/toolkit/docs/4.0/security/prewsaa/admin-index.html#id2838016

but that would be confusing as the user was using a WS service.

I suggest a security documentation workover, including merging the prews and ws
docs and adding a faq.
------- Comment #1 From 2006-11-06 18:06:33 -------
So I am seeing this issue with GT 4.0.3. When using globusrun-ws and
the default host authorization I get the error shown in the bug
report.

The bug report states "...It is obviously a dns problem...". That
makes sense to me. A reverse lookup on the IP address is returning
something of the form "::ffff:192.168.0.11".

What doesn't make sense to me, however, is that a globus-url-copy
command executed on the same machine to the same remote machine using
host authorization works and I do not get the error above.

I have checked and verified that the host certificate and container
certificate are the same and all the other things that can usually go
wrong (permissions and the like) are fine.

So it looks like globus-url-copy and globusrun-wc exercise different
GSI code. Is that correct?

If so, is there any reason globusrun-ws cannot do whatever it is that
globus-url-copy does to be "successful"?