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
________________________________________________
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
________________________________
From: Albert Rossi <[log in to unmask]>
Sent: Thursday, August 22, 2019 7:16:31 AM
To: Michal Kamil Simon <[log in to unmask]>; xrootd-dev <[log in to unmask]>; [log in to unmask] <[log in to unmask]>
Subject: Re: Xrootd server does not communicate security level using ProtocolResponse
Ah, client protocol request. Got it.
________________________________________________
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
________________________________
From: Albert Rossi <[log in to unmask]>
Sent: Thursday, August 22, 2019 6:58:30 AM
To: Michal Kamil Simon <[log in to unmask]>; xrootd-dev <[log in to unmask]>; [log in to unmask] <[log in to unmask]>
Subject: Re: Xrootd server does not communicate security level using ProtocolResponse
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
________________________________________________
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
________________________________
From: Michal Kamil Simon <[log in to unmask]>
Sent: Thursday, August 22, 2019 2:51:18 AM
To: Albert Rossi <[log in to unmask]>; xrootd-dev <[log in to unmask]>; [log in to unmask] <[log in to unmask]>
Subject: RE: Xrootd server does not communicate security level using ProtocolResponse
Hi Albert,
I suppose that the triggering client (xrdcp 4.10.0) receives the correct secLvl and
signs its requests when communicating with source XRootD server, right?
(otherwise the TPC would failed earlier)
What is the protocol version that dCache TPC client sets in kXR_protocol request
(ClientProtocolRequest::clientpv) ? Signing is supported since protocol version
3.1.0, for older versions server will not provide the secLvl.
Cheers,
Michal
________________________________
From: [log in to unmask] [[log in to unmask]] on behalf of Albert Rossi [[log in to unmask]]
Sent: 21 August 2019 23:38
To: Michal Kamil Simon; xrootd-dev; [log in to unmask]
Subject: Re: Xrootd server does not communicate security level using ProtocolResponse
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
________________________________________________
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
________________________________
From: Michal Kamil Simon <[log in to unmask]>
Sent: Wednesday, August 21, 2019 3:34:52 PM
To: Albert Rossi <[log in to unmask]>; xrootd-dev <[log in to unmask]>; [log in to unmask] <[log in to unmask]>
Subject: RE: Xrootd server does not communicate security level using ProtocolResponse
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<https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.slac.stanford.edu_cgi-2Dbin_wa-3FSUBED1-3DXROOTD-2DDEV-26A-3D1&d=DwMFAw&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=tGrw2IEZTBDg-KwALfQDMIjj1BNOOVsKqganQT9yi3A&s=rktf0uF8PdRn58RiCa4KWu8xbvQZHDmkOy9mGG0kuQ4&e=>
________________________________
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<https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.slac.stanford.edu_cgi-2Dbin_wa-3FSUBED1-3DXROOTD-2DL-26A-3D1&d=DwMFAw&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=fhacQ6oaL5iGCZiC1CKKS3cVDm6RDCP0D07g65eN6_Q&s=JC_Z6ZbyWSR4L08uEbWq7u-nR2zG5aEBVQQryUKzV4g&e=>
########################################################################
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
