 |
 |
Let me just add, the reason it was disabled was due to scurity concerns. We didn't want delegation implicitly enabled in situations where the client either didn't want delegation or was unaware that delegation would occur. Andy On Wed, 4 Mar 2020, Michal Kamil Simon wrote: > Hi Diego, > > Since 4.9.0 xrdcp will allow delegation only if it has been requested explicitly, e.g. > > xrdcp --tpc delegate only .... > > (it will also reset XrdSecGSIDELEGPROXY) > > Currently, the only way to request delegation is when doing a third-party-copy. > So yes, one could say it's disabled on purpose. If you have a valid use-case and > a strong desire I could life the XrdSecGSIDELEGPROXY untouched in case of > classical copy jobs. > > Cheers, > Michal > ________________________________ > From: [log in to unmask] [[log in to unmask]] on behalf of Diego Ciangottini [[log in to unmask]] > Sent: 04 March 2020 14:35 > To: [log in to unmask] > Subject: XrdSecGSIDELEGPROXY ignored by xrdcp > > > Hello everyone, > > I'm playing a bit with several authN/Z combination for XCache and I'm facing a problem when trying to use user proxy delegation. > > Even though I know that this is a "controversial" feature, it might be useful in some special cases. So, the problem is the following: > > - the cache server is v4.11.2 and configured with (*) > > - I'm then trying the following command with xrdcp v4.11.2: > > XrdSecGSIDELEGPROXY=2 XrdSecDEBUG=1 xrdcp -f root://131.154.96.135:31094//test/test.txt /dev/null > > - one thing that already sounds strange is the output (**) where I see: > > 200304 14:02:50 16321 secgsi_InitOpts: Proxy delegation option: 0 > > - and on server side accordingly: > > 200304 13:02:50 28389 secgsi_ErrF: Secgsi: ErrParseBuffer: error getting user proxies: kXGS_init > > Am I missing something or it's indeed a problem client side? Is it even supposed to work or is it disabled on purpose? > > Cheers, > Diego > > > (*) > all.export / stage > oss.localroot /data/ > > xrootd.trace debug > xrd.trace debug > sec.trace debug > > xrd.port 31094 > > xrootd.seclib /usr/lib64/libXrdSec.so > sec.protocol /usr/lib64 gsi \ > -dlgpxy:1 -authzpxy:1 -exppxy:/tmp/x509up_g<group> \ > -certdir:/etc/grid-security/certificates \ > -cert:/etc/grid-security/xrd/cloud-vm135.cloud.cnaf.infn.it.crt \ > -key:/etc/grid-security/xrd/cloud-vm135.cloud.cnaf.infn.it.key \ > -d:3 \ > -ca:1 -crl:0 \ > -gridmap:/dev/null \ > -vomsfun:/usr/lib64/libXrdSecgsiVOMS.so -vomsfunparms:certfmt=raw|dbg > > ofs.authorize 1 > > acc.audit deny > acc.authdb /etc/xrootd/Authfile-auth-X509-vo > sec.protbind * gsi > > > ofs.osslib libXrdPss.so > pss.cachelib libXrdFileCache.so > > pss.origin 193.204.89.93:1094 > > pfc.diskusage 0.95 0.99 > pfc.ram 8G > > pfc.blocksize 512k > pfc.prefetch 0 > > (**) > sec_Client: protocol request for host 131.154.96.135 token='&P=gsi,v:10400,c:ssl,ca:eec62e9c.0|bf6400bf.0' > sec_PM: Loaded gsi protocol object from libXrdSecgsi.so > 200304 14:02:50 16321 secgsi_InitOpts: *** ------------------------------------------------------------ *** > 200304 14:02:50 16321 secgsi_InitOpts: Mode: client > 200304 14:02:50 16321 secgsi_InitOpts: Debug: 1 > 200304 14:02:50 16321 secgsi_InitOpts: CA dir: /afs/cern.ch/user/d/dciangot/CA > 200304 14:02:50 16321 secgsi_InitOpts: CA verification level: 1 > 200304 14:02:50 16321 secgsi_InitOpts: CRL dir: ,/afs/cern.ch/user/d/dciangot/CA/ > 200304 14:02:50 16321 secgsi_InitOpts: CRL extension: .r0 > 200304 14:02:50 16321 secgsi_InitOpts: CRL check level: 1 > 200304 14:02:50 16321 secgsi_InitOpts: CRL refresh time: 86400 > 200304 14:02:50 16321 secgsi_InitOpts: Certificate: /afs/cern.ch/user/d/dciangot/.globus/usercert.pem > 200304 14:02:50 16321 secgsi_InitOpts: Key: /afs/cern.ch/user/d/dciangot/.globus/userkey.pem > 200304 14:02:50 16321 secgsi_InitOpts: Proxy file: /tmp/x509up_u34086 > 200304 14:02:50 16321 secgsi_InitOpts: Proxy validity: 12:00 > 200304 14:02:50 16321 secgsi_InitOpts: Proxy dep length: 0 > 200304 14:02:50 16321 secgsi_InitOpts: Proxy bits: 512 > 200304 14:02:50 16321 secgsi_InitOpts: Proxy sign option: 1 > 200304 14:02:50 16321 secgsi_InitOpts: Proxy delegation option: 0 > 200304 14:02:50 16321 secgsi_InitOpts: Allowed server names: [*/]<target host name>[/*] > 200304 14:02:50 16321 secgsi_InitOpts: Crypto modules: ssl > 200304 14:02:50 16321 secgsi_InitOpts: Ciphers: aes-128-cbc:bf-cbc:des-ede3-cbc > 200304 14:02:50 16321 secgsi_InitOpts: MDigests: sha1:md5 > 200304 14:02:50 16321 secgsi_InitOpts: Trusting DNS for hostname checking > 200304 14:02:50 16321 secgsi_InitOpts: *** ------------------------------------------------------------ *** > sec_PM: Using gsi protocol, args='v:10400,c:ssl,ca:eec62e9c.0|bf6400bf.0' > 200304 14:02:50 16321 cryptossl_X509::CertType: certificate has 3 extensions > 200304 14:02:50 16321 secgsi_GetCA: CRL is missing or expired: ignoring (CRLCheck: 1) > 200304 14:02:50 16321 cryptossl_X509::CertType: certificate has 3 extensions > 200304 14:02:50 16321 cryptossl_X509::CertType: certificate has 9 extensions > 200304 14:02:50 16321 cryptossl_X509::CertType: certificate has 4 extensions > [0B/0B][100%][==================================================][0B/s] > Run: [ERROR] Server responded with an error: [3010] Unable to open /test/test.txt; permission denied > > > ________________________________ > > 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 > > ######################################################################## > 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 > ######################################################################## 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