Print

Print


Hi Albert,

The response to kXR_protocol request should contain security level gif signing is enabled.

That said, could you give me more details on your scenario: which client do you use to trigger
the third-party-copy? Are both source and destination dCache endpoints? what client is used
on the destination side to carry out the transfer? is authentication required for a connection
from destination to source, is it GSI?

Cheers,
Michal


________________________________
From: [log in to unmask] [[log in to unmask]] on behalf of Albert Rossi [[log in to unmask]]
Sent: 21 August 2019 20:21
To: xrootd-dev; [log in to unmask]
Subject: Xrootd server does not communicate security level using ProtocolResponse


Hi again,


With the server (4.10) set to

sec.level all pedantic

it requires all post-authentication requests to be signed, as it should.

However, in order to do so, the third-party-copy client must know about this.

It was my understanding that this was conveyed by the Protocol Request.

Yet, when logging on to that server, the dCache TPC client finds:

sendProtocolRequestForClient to fndcatemp2:1095, channel 5c8a91fe, stream 1.
21 Aug 2019 12:54:55 (dmsdca19-2) [] Decoder fndcatemp2:1095, channel 5c8a91fe: adding protocol response.
21 Aug 2019 12:54:55 (dmsdca19-2) [] responseReceived, channel 5c8a91fe, stream 1, requestId = kXR_protocol.
21 Aug 2019 12:54:55 (dmsdca19-2) [] Protocol response on fndcatemp2:1095, channel 5c8a91fe, stream 1, received, signing policy (secLvl 0)(overrides {})(force false); status 0.
21 Aug 2019 12:54:55 (dmsdca19-2) [] Protocol request to fndcatemp2:1095, channel 5c8a91fe, stream 1, succeeded; sending login request.

That is, the ProtocolResponse header info does not convey this back.

Subsequently, when the open request is sent to the source server (xrootd), it complains that the request was not signed:

sendOpenRequest to fndcatemp2:1095, channel 5c8a91fe, stream 1, path [log in to unmask]&org.dcache.uuid=d4776fc5-cd78-41ac-99ba-983975fcf2a4.
21 Aug 2019 12:54:55 (dmsdca19-2) [] Decoder fndcatemp2:1095, channel 5c8a91fe: adding error response.
21 Aug 2019 12:54:55 (dmsdca19-2) [] Exception caught on channel 5c8a91fe: org.dcache.xrootd.core.XrootdException: Request not [log in to unmask]


Note that the dCache server does send back the correct secLvl and force values:


sendProtocolRequestForClient to fndcatemp1:1095, channel f387d5b6, stream 1.
21 Aug 2019 13:18:40 (dmsdca19-1.1) [] Decoder fndcatemp1:1095, channel f387d5b6: adding protocol response.
21 Aug 2019 13:18:40 (dmsdca19-1.1) [] responseReceived, channel f387d5b6, stream 1, requestId = kXR_protocol.
21 Aug 2019 13:18:40 (dmsdca19-1.1) [] Protocol response on fndcatemp1:1095, channel f387d5b6, stream 1, received, signing policy (secLvl 4)(overrides {})(force true); status 0.
21 Aug 2019 13:18:40 (dmsdca19-1.1) [] Protocol request to fndcatemp1:1095, channel f387d5b6, stream 1, succeeded; sending login request.



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


________________________________________________
Albert L. Rossi
Application Developer & Systems Analyst III
Scientific Computing Division, Data Movement Development
FCC 229A
Mail Station 369 (FCC 2W)
Fermi National Accelerator Laboratory
Batavia, IL 60510
(630) 840-3023

________________________________

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