Thanks, Wei.  That much was clear.  The dCache prototype is advertising its version as 10400, so the 4.9 client knows it is talking to a newer server.


It was the filter Gerri mentioned that was not allowing me to see the signed proxy returned because I was looking for it during a normal 2 party copy.

However, I'm fiddling a bit with something else having to do with session key encryption right now, and may (or may not !) have another question for you all ...

we'll see ๐Ÿ˜Š

thanks for all your input.

Al


From: Yang, Wei <[log in to unmask]>
Sent: Wednesday, March 6, 2019 1:44 PM
To: Albert Rossi; ganis
Cc: xrootd-dev; xrootd-l
Subject: Re: activating client delegation
 
HI Albert,

In addition to the unix environment variable, two other things at the server have to happen: the GSI protocol version number has to be >= XrdSecgsiVersDHsigned, and in that case, the client also expect the server to sign the symmetric key's public parameters (Diffie-Hellman parameters) with server's private key. Otherwise, the 4.9 client will think that it is talking to an older server (with doesn't sign the public parameters), and will refuse to delegate to X509 credential to the server (but will agree to do other things).

See line 1826 and 1830 at https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_xrootd_xrootd_blob_master_src_XrdSecgsi_XrdSecProtocolgsi.cc&d=DwIGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=aD2ek6ppwHIBR7XmIfXQvRWD2AmkcIMluZEORDhL4uk&s=FQkqm6CEhI5fDvE4z2hysNW94UHbXtvNv-6iHWl-BSU&e=


regards,
--
Wei Yang  |  mailto:[log in to unmask]  |  650-926-3338 (O)


From: <[log in to unmask]> on behalf of Albert Rossi <[log in to unmask]>
Date: Wednesday, March 6, 2019 at 8:04 AM
To: ganis <[log in to unmask]>
Cc: xrootd-dev <[log in to unmask]>, xrootd-l <[log in to unmask]>
Subject: Re: activating client delegation

Ah, OK, thanks Gerri.

I will check to make sure delegation does happen then with the --tpc option.

Just wanted to make sure I wasn't skipping something.

-Al


From: ganis <[log in to unmask]>
Sent: Wednesday, March 6, 2019 9:43 AM
To: Albert Rossi
Cc: xrootd-dev; [log in to unmask]
Subject: Re: activating client delegation
 

Hi Albert,

This is because of the security check in xrdcp that filters the setting out unless itโ€™s a real TPC case.

The easiest way around is to use xrdfs, for example like this

   $ xrdfs root://your.server.url  stat /path/to/your/file

Gerri


On 06 Mar 2019, at 15:54, Albert Rossi <mailto:[log in to unmask]> wrote:

Hi Andy,

yes, that is the env variable I have been setting (see the script I mentioned below).

There is something wrong, then, with the way I am doing it, because it does not seem to be working.

i.e.,

> #!/bin/bash
>
> export LD_LIBRARY_PATH="/usr/share/xrootd/xrootd-4.9.0/lib64:$LD_LIBRARY_PATH"
> export XrdSecGSIDELEGPROXY=1
>
> /usr/share/xrootd/xrootd-4.9.0/bin/xrdcp $@
>

does not work for me.

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: Andrew Hanushevsky <mailto:[log in to unmask]>
Sent: Wednesday, March 6, 2019 8:50 AM
To: Albert Rossi
Cc: xrootd-dev; mailto:[log in to unmask]
Subject: Re: activating client delegation
 
Hi Albert,

This is handled by an envar XrdSecGSIDELEGPROXY and is documented in the 
security reference
https://urldefense.proofpoint.com/v2/url?u=http-3A__xrootd.org_doc_dev49_sec-5Fconfig.htm&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=Si51LbJlKCEyx2WfKgPV8W0xh3B-16Xj5Mr6yV2RSAY&s=Hc0rm9dtHt1Ayif3JHCgkTFwgTRXRG4ZPfmxfZptGm4&e=

Specifically, in section
https://urldefense.proofpoint.com/v2/url?u=http-3A__xrootd.org_doc_dev49_sec-5Fconfig.htm-23-5FToc517294107&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=Si51LbJlKCEyx2WfKgPV8W0xh3B-16Xj5Mr6yV2RSAY&s=ToMmFfGRbGkTb02agcNUN2GeJD9cXHKonGBxfRPXmDw&e=

It is done this way because the client does not have a config file, so it 
relies on envars to enable specific behaviour.

Andy

On Wed, 6 Mar 2019, Albert Rossi wrote:

> Hello,
>
>
> What is necessary in order to get the 4.9 xrdcp client to sign proxy requests besides setting the env variable?
>
>
> I cannot find anything in the documentation that describes this (your GSI document merely mentions the kgsiHandshakeOpts enum that is used internally).
>
>
> I have looked at
>
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__xrdsecprotocolgsi.cc_&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=fF0KR0wE1Zzuk6IBOCJq7m4I-LNosOxgdIY9eTFJWm0&s=QNUBuFks7BoZ-6XAJYT7Ddvm20fZBbmMtvdqdJ8basQ&e=
>
>
> With respect to the client, here is what I see.
>
>
> Your extern C initializing function, char *XrdSecProtocolgsiInit, at l. 2557 does:
>
>
> cenv = getenv("XrdSecGSIDELEGPROXY");
> if (cenv)
>         opts.dlgpxy = atoi(cenv);
>
> this function does a tail call on the C++ initializer:  char *XrdSecProtocolgsi::Init(gsiOptions opt, XrdOucErrInfo *erp)
>
> which in turn, at l. 989, sets up the options for the client:
>
>      // Delegate proxy options
>      if (opt.dlgpxy > 0) {
>         PxyReqOpts |= kOptsSigReq;
>         if (opt.dlgpxy == 2) {
>            PxyReqOpts |= kOptsFwdPxy;
>         } else {
>            PxyReqOpts |= kOptsDlgPxy;
>         }
>      }
>
>
> So, from the looks of it, all it should take to get the client to sign delegation requests is to set the env var XrdSecGSIDELEGPROXY to 1.
>
>
> The script I am using to run the 4.9 client has this:
>
>
> #!/bin/bash
>
> export LD_LIBRARY_PATH="/usr/share/xrootd/xrootd-4.9.0/lib64:$LD_LIBRARY_PATH"
> export XrdSecGSIDELEGPROXY=1
>
> /usr/share/xrootd/xrootd-4.9.0/bin/xrdcp $@
>
>
>
> and yet, the dCache server/door tells me on the sigpxy step that it has received a kXRS_message bucket with the following:
>
>
> "client cannot sign request; Not allowed to sign proxy requests."
>
>
> Is there something else that needs to be done in order to get the client to sign proxy requests?
>
>
> 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
>
> ########################################################################
> Use REPLY-ALL to reply to list
>
> To unsubscribe from the XROOTD-DEV list, click the following link:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.slac.stanford.edu_cgi-2Dbin_wa-3FSUBED1-3DXROOTD-2DDEV-26A-3D1&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=Si51LbJlKCEyx2WfKgPV8W0xh3B-16Xj5Mr6yV2RSAY&s=7Swm5XvoFU7BM2FilUQyaUIPVWPb03Lmr-k631NqojQ&e=
>


Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.slac.stanford.edu_cgi-2Dbin_wa-3FSUBED1-3DXROOTD-2DDEV-26A-3D1&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=fF0KR0wE1Zzuk6IBOCJq7m4I-LNosOxgdIY9eTFJWm0&s=dkHo7CkF2Fg3xpBCQr6TaGQMJbPrqYtkcHceNxIuKr0&e=



Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-L list, click the following link:
https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.slac.stanford.edu_cgi-2Dbin_wa-3FSUBED1-3DXROOTD-2DL-26A-3D1&d=DwIGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=aD2ek6ppwHIBR7XmIfXQvRWD2AmkcIMluZEORDhL4uk&s=OHCau_Q1cmQO2OZoa-PXhqa78pWqW46kNXptSZXRsGE&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