190822 10:06:58 27718 ?:23@otfrid
XrootdProtocol: 0000 req=login dlen=92
vs
190822 10:06:59 27719 ?:25@dmsdca19 XrootdProtocol: 0003 req=login dlen=0
There is a difference in terms of how the protocol request is negotiated
Not quite sure what the ordering difference means, but in particular I see
190822 10:06:58 27718 ?:23@otfrid
XrootdProtocol: 0000 req=login dlen=92
vs
190822
10:06:59 27719 ?:25@dmsdca19 XrootdProtocol: 0003 req=login dlen=0
Attached full client and server logs
Unfortunately there is no free-standing dCache client. The client is specific to TPC functionality and is embedded in the dCache xrootd pool code.
What if I ratcheted up the debug level on the xrootd server and sent you that output?
Al
OK. Let me give a status report here.
The protocol version is now set to 0x00000400.
There was a bug in the byte order of my header. kXR_secreqs now appears in the correct position.
BUT, it is still no working.
22 Aug 2019 08:49:47 (dmsdca19-2.1) [] sendProtocolRequestForClient to fndcatemp2:1095, channel 06ccd0fd, stream 2.
22 Aug 2019 08:49:47 (dmsdca19-2.1) [] sendProtocolRequestForClient to (stream 2)(version 400)
22 Aug 2019 08:49:47 (dmsdca19-2.1) [] Decoder fndcatemp2:1095, channel 06ccd0fd: adding protocol response.
22 Aug 2019 08:49:47 (dmsdca19-2.1) [] responseReceived, channel 06ccd0fd, stream 2, requestId = kXR_protocol.
22 Aug 2019 08:49:47 (dmsdca19-2.1) [] Protocol response on fndcatemp2:1095, channel 06ccd0fd,
stream 2, received, signing policy (secLvl 0)(overrides {})(force false); status 0.
Michal, any idea what else could be wrong?
________________________________________________
P.S. found the documentation.
9) Protocol
version 3.1.0 introduced a mechanism to verify that requests came from an authenticated client. Pre 3.1.0 servers should never return security information when requested to do so. Servers that have no security requirements need not return any security information
when requested to do so. When security information has not been returned the client should assume that no requirements exist.
I have a question, though.
If the client says it supports a version < 3.1.0, why does the server then wait until the first signed message to reject it? If the server requires signing and the client says it doesn't, should the connection be immediately refused?
Al
Ah, client protocol request. Got it.
First question. Yes
Second question: by protocol, you mean xrootd, not GSI, correct?
That's the issue, in any case. Is this documented somewhere?
Thanks, Al
Sure Michal.
The case where you do not see the secLvl set in the protocol response is as follows:
Client: otfrid.fnal.gov xrdcp 4.10.0
Dest: dCache trunk/master, with signing level = 4 (but that doesn't matter here)
Src: xrootd 4.10 server with the sec level set as indicated (pedantic).
The third-party client in this case is the embedded dCache client.
The transfer uses --tpc delegation only.
The third-party client thus logs in to the xrootd source server using the delegated credential/gsi.
It is this third-party client which then does not sign the open request because it did not see secLvl > 0 in the protocol response from the source server.
When, however, I do:
Client: otfrid.fnal.gov xrdcp 4.10.0
Dest: dCache trunk/master, with signing level = 4 (but that doesn't matter here)
Src: dCache trunk/master, with signing level = 4
that is, a totally dCache-based transfer, the embedded client does sign the request because the dCache source does return the secLvl as = 4 in the protocol response.
HTH,
Al
Hi again,
If the ProtocolResponse is not the place to look for this information, where should the client go to find out about the security level?
Al
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
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1
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
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