I don't think the cache currently has a way to use the delegated credential, even if the client allows to delegate. -- Wei Yang | [log in to unmask]<mailto:[log in to unmask]> | 650-926-3338 (O) From: <[log in to unmask]> on behalf of Diego Ciangottini <[log in to unmask]> Organization: INFN Date: Wednesday, March 4, 2020 at 9:47 AM To: Michal Kamil Simon <[log in to unmask]>, xrootd-l <[log in to unmask]> Subject: Re: XrdSecGSIDELEGPROXY ignored by xrdcp Hi Michal, thanks for the clarification. The use case that we are evaluating is a multi-group scernario where it is possible to share the access to the same cache daemon. Different namespace mappings are then managed by VOMS groups both on the cache and on origin server. I'm aware of the motivation/discussion for which this has been disabled, but let's say that in some controlled scenarios, as the one we are investigating, having the possibility of enabling it explicitly could be very useful. Diego Il 3/4/2020 4:08 PM, Michal Kamil Simon ha scritto: 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]<mailto:[log in to unmask]> [[log in to unmask]<mailto:[log in to unmask]>] on behalf of Diego Ciangottini [[log in to unmask]<mailto:[log in to unmask]>] Sent: 04 March 2020 14:35 To: [log in to unmask]<mailto:[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