Hi Andy,
I put this as a pull request so that we can discuss if I misunderstood something related to the desired behaviour of the client.
The problem: the parameters included in the opaque part of a URL that deal with authentication (i.e. xrd.wantprot, xrd.krb5ccname etc) are not properly forwarded when redirections are followed.
The assumption I made is that if a client requests a certain type of authentication then this should be enforced with respect to all parties that it contacts during the transfer.
First of all, there is a clear inconsistency between the behaviour when the XrdSecPROTOCOL is used and when the xrd.wantproto
is added to the URL. This comes from the fact that in https://github.com/xrootd/xrootd/blob/master/src/XrdSec/XrdSecPManager.cc#L153 the process env variable is always visible if set, while the xrd.wantprot
might not if it was not properly forwarded.
The source of the problem is that when we get redirected a new channel needs to be opened to the new destination. At this point also the authentication takes place but the URL used by this step does not contain any opaque info at all. In the code below this is the pUrl
variable.
This patch saves any xrd.* parameters present in the initial url request and appends them to the new redirection url. In this way the behaviour is consistent with the XrdSecPROTOCOL approach.
I have tested this using a default instance of EOS where the load-balancer requires krb5 authentication and the data server accepts unix.
1. Use the XrdSecPROTOCOL
and krb5 authentication
env XrdSecPROTOCOL=krb5 xrdcp -f -d 1 root://pcitdss1400.cern.ch//eos/replica/test.dat /tmp/dump
[2016-05-11 19:17:47.768371 +0200][Error ][XRootDTransport ] [pcitdss1400.cern.ch:2001 #0.0] No protocols left to try
[2016-05-11 19:17:47.768451 +0200][Error ][AsyncSock ] [pcitdss1400.cern.ch:2001 #0.0] Socket error while handshaking: [FATAL] Auth failed
[2016-05-11 19:17:47.768525 +0200][Error ][PostMaster ] [pcitdss1400.cern.ch:2001 #0] Unable to recover: [FATAL] Auth failed.
[0B/0B][100%][==================================================][0B/s]
Run: [ERROR] Server responded with an error: [3005] Unable to open file /eos/replica/test.dat; Machine is not on the network
As expected this fails since the data server only accepts unix. Data server is on the same machine but on a different port 2001 instead of the default 1094.
2. Enforce the authentication using the opaque info
[esindril@pcitdss1401 build]$ xrdcp -f -d 1 "root://pcitdss1400.cern.ch//eos/replica/test.dat?xrd.wantprot=krb5&xrd.krb5ccname=/tmp/krb5cc_58602" /tmp/dump
[2.383kB/2.383kB][100%][==================================================][2.383kB/s]
This unexpectedly works because the opaque info is not forwarded to the data-server.
1. The same behaviour as in A1.
2.
xrdcp -f -d 1 "root://pcitdss1400.cern.ch//eos/replica/test.dat?xrd.wantprot=krb5&xrd.krb5ccname=/tmp/krb5cc_58602" /tmp/dump
[2016-05-11 19:24:48.370748 +0200][Error ][XRootDTransport ] [pcitdss1400.cern.ch:2002 #0.0] No protocols left to try
[2016-05-11 19:24:48.370790 +0200][Error ][AsyncSock ] [pcitdss1400.cern.ch:2002 #0.0] Socket error while handshaking: [FATAL] Auth failed
[2016-05-11 19:24:48.370861 +0200][Error ][PostMaster ] [pcitdss1400.cern.ch:2002 #0] Unable to recover: [FATAL] Auth failed.
[0B/0B][100%][==================================================][0B/s]
Run: [ERROR] Server responded with an error: [3005] Unable to open file /eos/replica/test.dat; Machine is not on the network
Now this matches the behaviour from A1 - which is what we expected.
And to have this transfer work properly we should also put unix
in the list of protocols accepted by the client so that we can connect to the data server. And this indeed works:
esindril@esdss001 build]$ xrdcp -f -d 1 "root://pcitdss1400.cern.ch//eos/replica/test.dat?xrd.wantprot=krb5,unix&xrd.krb5ccname=/tmp/krb5cc_58602" /tmp/dump
[2.383kB/2.383kB][100%][==================================================][2.383kB/s]
Is there any particular scenario in which one would not want to forward this info?
Thanks,
Elvin
https://github.com/xrootd/xrootd/pull/364
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1