kXR_query not issued with original protocol during TPC

[alrossi]

This is not an urgent issue, but does generate a little unexpected noise from the xrdcp client.

In dCache, we have continued to support STRICT vs OPTIONAL TLS on an xroot door or pool. If the endpoint is STRICT, the client will get a goToTLS from the protocol request; otherwise, it is up to the client to request TLS using xroots.

Now, here is a Two-Party read authenticating to a dCache door which is OPTIONAL. If I use xroots, all is fine (I am using a ZTN token):

arossi@fndcatemp1 ~]$ xrdcp5x -f xroots://fndcatemp2.fnal.gov:1095//pnfs/fs/usr/fermilab/users/arossi/volatile/data_1b /dev/null
[1B/1B][100%][==================================================][1B/s]  

However, when I use that door (on 1095) as the source of a native xroot TPC, I see:

[arossi@fndcatemp1 ~]$ xrdcp5x --tpc only xroots://fndcatemp2.fnal.gov:1095//pnfs/fs/usr/fermilab/users/arossi/volatile/data_1b xroots://fndcatemp2.fnal.gov:1094//pnfs/fs/usr/fermilab/users/arossi/volatile/data-`suffix`
security protocol 'ztn' disallowed for non-TLS connections.
[1B/1B][100%][==================================================][0B/s]  

The TPC succeeds. The warning, in fact, is not generated by the transfer logins, but by the kXR_query against the source: `

2-09 10:11:54.324893 -0600][Dump   ][PostMaster        ] [fndcatemp2.fnal.gov:1095] Sending message kXR_query (code: kXR_Qconfig, arg length: 4) (0x1740020) through substream 0 expecting answer at 0
[2023-02-09 10:11:54.325701 -0600][Debug  ][PostMaster        ] [fndcatemp2.fnal.gov:1095] Found 1 address(es): [::ffff:131.225.240.93]:1095
[2023-02-09 10:11:54.325791 -0600][Debug  ][AsyncSock         ] [fndcatemp2.fnal.gov:1095.0] Attempting connection to [::ffff:131.225.240.93]:1095
[2023-02-09 10:11:54.325866 -0600][Debug  ][Poller            ] Adding socket 0x173e610 to the poller
[2023-02-09 10:11:54.326058 -0600][Debug  ][AsyncSock         ] [fndcatemp2.fnal.gov:1095.0] Async connection call returned
[2023-02-09 10:11:54.326117 -0600][Debug  ][XRootDTransport   ] [fndcatemp2.fnal.gov:1095.0] Sending out the initial hand shake + kXR_protocol
[2023-02-09 10:11:54.326168 -0600][Dump   ][AsyncSock         ] [fndcatemp2.fnal.gov:1095.0] Wrote a message:  (0x740010d0), 44 bytes
[2023-02-09 10:11:54.332918 -0600][Dump   ][XRootDTransport   ] [msg: 0x74079a40] Expecting 8 bytes of message body
[2023-02-09 10:11:54.332964 -0600][Dump   ][AsyncSock         ] [fndcatemp2.fnal.gov:1095.0] Received message header, size: 8
[2023-02-09 10:11:54.332986 -0600][Dump   ][AsyncSock         ] [fndcatemp2.fnal.gov:1095.0] Received a message of 16 bytes
[2023-02-09 10:11:54.333006 -0600][Debug  ][XRootDTransport   ] [fndcatemp2.fnal.gov:1095.0] Got the server hand shake response (type: manager [], protocol version 500)
[2023-02-09 10:11:54.334823 -0600][Dump   ][XRootDTransport   ] [msg: 0x7408b9c0] Expecting 8 bytes of message body
[2023-02-09 10:11:54.334869 -0600][Dump   ][AsyncSock         ] [fndcatemp2.fnal.gov:1095.0] Received message header, size: 8
[2023-02-09 10:11:54.334891 -0600][Dump   ][AsyncSock         ] [fndcatemp2.fnal.gov:1095.0] Received a message of 16 bytes
[2023-02-09 10:11:54.334915 -0600][Debug  ][XRootDTransport   ] [fndcatemp2.fnal.gov:1095.0] kXR_protocol successful (type: manager [], protocol version 500)
[2023-02-09 10:11:54.335121 -0600][Debug  ][XRootDTransport   ] [fndcatemp2.fnal.gov:1095.0] Sending out kXR_login request, username: arossi, cgi: xrd.cc=us&xrd.tz=-6&xrd.appname=xrdcp&xrd.info=&xrd.hostname=fndcatemp1.fnal.gov&xrd.rn=v20220328-b5f279d, dual-stack: false, private IPv4: false, private IPv6: false
[2023-02-09 10:11:54.335180 -0600][Dump   ][AsyncSock         ] [fndcatemp2.fnal.gov:1095.0] Wrote a message:  (0x74079a40), 129 bytes
[2023-02-09 10:11:54.336716 -0600][Dump   ][XRootDTransport   ] [msg: 0x740010d0] Expecting 70 bytes of message body
[2023-02-09 10:11:54.336761 -0600][Dump   ][AsyncSock         ] [fndcatemp2.fnal.gov:1095.0] Received message header, size: 8
[2023-02-09 10:11:54.336784 -0600][Dump   ][AsyncSock         ] [fndcatemp2.fnal.gov:1095.0] Received a message of 78 bytes
[2023-02-09 10:11:54.336806 -0600][Debug  ][XRootDTransport   ] [fndcatemp2.fnal.gov:1095.0] Logged in, session: 60c82f6d4de883a7f1824946bde8e7ce
[2023-02-09 10:11:54.336821 -0600][Debug  ][XRootDTransport   ] [fndcatemp2.fnal.gov:1095.0] Authentication is required: &P=gsi,v:10400,c:ssl,ca:f5f0dfc2&P=ztn,0:4096:&P=unix
[2023-02-09 10:11:54.336836 -0600][Debug  ][XRootDTransport   ] [fndcatemp2.fnal.gov:1095.0] Sending authentication data
[2023-02-09 10:11:54.336880 -0600][Debug  ][XRootDTransport   ] [fndcatemp2.fnal.gov:1095.0] Trying to authenticate using gsi
[2023-02-09 10:11:54.337234 -0600][Debug  ][XRootDTransport   ] [fndcatemp2.fnal.gov:1095.0] Cannot get credentials for protocol gsi: Secgsi: ErrParseBuffer: error getting user proxies: kXGS_init
security protocol 'ztn' disallowed for non-TLS connections.
[2023-02-09 10:11:54.337608 -0600][Debug  ][XRootDTransport   ] [fndcatemp2.fnal.gov:1095.0] Trying to authenticate using unix
[2023-02-09 10:11:54.337858 -0600][Dump   ][AsyncSock         ] [fndcatemp2.fnal.gov:1095.0] Wrote a message:  (0x74077ce0), 40 bytes
[2023-02-09 10:11:54.340539 -0600][Dump   ][XRootDTransport   ] [msg: 0x740010d0] Expecting 0 bytes of message body
[2023-02-09 10:11:54.340585 -0600][Dump   ][AsyncSock         ] [fndcatemp2.fnal.gov:1095.0] Received message header, size: 8
[2023-02-09 10:11:54.340601 -0600][Dump   ][AsyncSock         ] [fndcatemp2.fnal.gov:1095.0] Received a message of 8 bytes
[2023-02-09 10:11:54.340627 -0600][Debug  ][XRootDTransport   ] [fndcatemp2.fnal.gov:1095.0] Authenticated with unix.

If we weren't allowing anonymous reads (using the unix protocol), this query would fail.

I was wondering what your rationale was for not applying the client-requested protocol (in this case, xroots) to all requests to that endpoint?

Thanks, Al

[abh3]

We have an identical situation in xrootd. TLS can be required (i.e., STRICT) or optional (in xrootd it's required or optional by request category so a bit more complicated). The same issue arose when TLS was not required. We solved it by making TLS required the moment you enable any security protocol that requires the use of TLS; in this case ztn. Then, as you have noted, making it required avoids the whole issue.

[alrossi]

Thanks for the reply, Andy.

I have another question which is not on the same topic. I don't want to open another issue, because it's not something I think xrootd needs to do; it's just about whether xrootd does handle a particular situation and how it does so. Perhaps I could email you instead?

Cheers, Al

[xrootd-dev]

Hi Albert, Sure, not a problem! Andy

…

On Thu, 9 Feb 2023, Albert Rossi wrote: Thanks for the reply, Andy. I have another question which is not on the same topic. I don't want to open another issue, because it's not something I think xrootd needs to do; it's just about whether xrootd does handle a particular situation and how it does so. Perhaps I could email you instead? Cheers, Al -- Reply to this email directly or view it on GitHub: #1903 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***> ######################################################################## 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

[abh3]

I think we have gone as far as we can with this, so I am closing this discussion.

[amadio]

Just want to note here that this may no longer be a problem after commits 47d64a7 and 8577e1f.