Bug 5915 - rftOptions sourceSubjectName being ignored
: rftOptions sourceSubjectName being ignored
Status: RESOLVED FIXED
: RFT
RFT
: 4.0.6
: Open Science Grid (OSG) Linux
: P3 critical
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2008-03-14 15:53 by
Modified: 2008-03-19 14:00 (History)


Attachments


Note

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


Description From 2008-03-14 15:53:50
The rftOption sourceSubjectName no longer appears to work in 4.0.6.  It did
work in 4.0.5.

Condor-G runs a gridftp server on the user's behalf; using the user's proxy as
the certificate.  This simplifies things.  To allow this to work, something
like:     "<rftOptions><sourceSubjectName>/C=US/O=Globus\
Alliance/OU=User/CN=101cab8c7eb.6a0bd7bc</source SubjectName></rftOptions>" is
included in the <transfer> requests in the job submission.

Expected behavior:   RFT successfully transfers the file.

Actual behavior: The transfer fails.  The following is observed in
var/container-real.log:

2008-03-14 14:24:41,070 ERROR service.TransferWork [WorkThread-51,run:494]
Transient transfer error 
Authentication with credential only failed on server vdt-rhas4-ia32.cs.wisc.edu
[Caused by: Authentication failed [Caused by: Opera
tion unauthorized (Mechanism level: Authorization failed. Expected
"/CN=host/vdt-rhas4-ia32.cs.wisc.edu" target but received "/C=US
/O=Globus Alliance/OU=User/CN=101cab8c7eb.6a0bd7bc")]]
Authentication with credential only failed on server
vdt-rhas4-ia32.cs.wisc.edu. Caused by Authentication failed. Caused by GSSExce
ption: Operation unauthorized (Mechanism level: Authorization failed. Expected
"/CN=host/vdt-rhas4-ia32.cs.wisc.edu" target but rec
eived "/C=US/O=Globus Alliance/OU=User/CN=101cab8c7eb.6a0bd7bc")
        at
org.globus.gsi.gssapi.GlobusGSSContextImpl.initSecContext(GlobusGSSContextImpl.java:509)
        at
org.globus.ftp.extended.GridFTPControlChannel.authenticate(GridFTPControlChannel.java:203)
        at org.globus.ftp.GridFTPClient.authenticate(GridFTPClient.java:99)
        at org.globus.ftp.GridFTPClient.authenticate(GridFTPClient.java:84)
        at
org.globus.transfer.reliable.service.cache.SingleConnectionImpl.<init>(SingleConnectionImpl.java:85)
        at
org.globus.transfer.reliable.service.cache.MlsdConnectionImpl.<init>(MlsdConnectionImpl.java:32)
        at
org.globus.transfer.reliable.service.cache.ConnectionManager.createNewConnection(ConnectionManager.java:370)
        at
org.globus.transfer.reliable.service.cache.ConnectionManager.getConnection(ConnectionManager.java:259)
        at
org.globus.transfer.reliable.service.client.URLExpanderClient.<init>(URLExpanderClient.java:60)
        at
org.globus.transfer.reliable.service.client.ClientFactory.createURLExpanderClient(ClientFactory.java:200)
        at
org.globus.transfer.reliable.service.TransferWork.run(TransferWork.java:448)
        at
org.globus.wsrf.impl.work.WorkManagerImpl$WorkWrapper.run(WorkManagerImpl.java:355)
        at java.lang.Thread.run(Thread.java:595)


The key part appears to be: Expected "/CN=host/vdt-rhas4-ia32.cs.wisc.edu"
target but received "/C=US/O=Globus Alliance/OU=User/CN=101cab8c7eb.6a0bd7bc"
RFT doesn't seem to have respected the
"<rftOptions><sourceSubjectName>/C=US/O=Globus\
Alliance/OU=User/CN=101cab8c7eb.6a0bd7bc</source SubjectName></rftOptions>" 
entry in the job.

This same job sent to a 1.0.5 installation that I believe is identically
configured works as expected.

If additional logs or tests would be helpful, please let me know.
------- Comment #1 From 2008-03-17 16:01:21 -------
Update package with this fix has been released here:
http://www.globus.org/toolkit/advisories.html
------- Comment #2 From 2008-03-19 14:00:15 -------
I just want to confirm that this advisory does fix the problem we are seeing. 

Thanks so much!

-alain