Print

Print


Hi Albert,

To answer your previous question: the 1st version of xrootd that supports signing
is 4.5.0, and yes the docs are available here:
http://xrootd.org/doc/dev45/XRdv310.htm#_Toc464248827
(see note 9. for the details about protocol version vs signing)

Yes, the protocol version should be 0x00000400 (hex 400).

Hmm, how can I get dcache xrootd client, so I can test it? Is it available as binary?

Cheers,
Michal

________________________________
From: Albert Rossi [[log in to unmask]]
Sent: 22 August 2019 15:58
To: Michal Kamil Simon; xrootd-dev; [log in to unmask]
Subject: Re: Xrootd server does not communicate security level using ProtocolResponse


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?

________________________________________________

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:35:28 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


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.


________________________________________________
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:29:04 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


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