XrdCl: Forward xrd.* parameters from the original to the redirection URL #364
Conversation
|
Yes, this is a sticky situation. The presumption here that the client has requested a particular set of security protocols via cgi as opposed to envar; though I think that this was likely a mistake on our part. Nonetheless, we have to provide backward comparability. Promoting the cgi elements in the client seems to solve the backward comparability issue. However, it would be good to understand why we even added the cgi approach in the first place. The history of that decision seems to be lost. I know the history of the envar approach but not the cgi approach. So, can you give me that? Mind you, I am not opposed to your pull request, I just want all of us to understand the history of why the patch is needed. |
|
Andreas wanted to select the authentication method on the per-server basis. |
|
AFAIR he needed it for his Fuse driver. |
|
Yes, this is used from EOS FUSE to select the authentication, more precisely the kerberos ticket on a per user basis. |
|
Well, then only you and Andreas know if this is a correct fix. I don’t think anyone else uses this feature. So, if it is, merge it in. Andy From: Elvin Sindrilaru Yes, this is used from EOS FUSE to select the authentication, more precisely the kerberos ticket on a per user basis. — Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: |
This fixes the issue with authentication when a client requests for example krb5 authentication and is then redirected - this info is lost when building the redirection URL.
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.wantprotois 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 thexrd.wantprotmight 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
pUrlvariable.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
XrdSecPROTOCOLand krb5 authenticationAs 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
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.
Now this matches the behaviour from A1 - which is what we expected.
And to have this transfer work properly we should also put
unixin the list of protocols accepted by the client so that we can connect to the data server. And this indeed works:Is there any particular scenario in which one would not want to forward this info?
Thanks,
Elvin