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.
### A. Without the patch
**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.
### B. With the patch
**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
You can view, comment on, or merge this pull request online at:
https://github.com/xrootd/xrootd/pull/364
-- Commit Summary --
* XrdCl: Forward xrd.* parameters from the original to the redirection URL
-- File Changes --
M src/XrdCl/XrdClXRootDMsgHandler.cc (109)
-- Patch Links --
https://github.com/xrootd/xrootd/pull/364.patch
https://github.com/xrootd/xrootd/pull/364.diff
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/xrootd/xrootd/pull/364
########################################################################
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
