 |
 |
Hi Andy, Michal, thank you. Indeed the main objective was to understand if this was an option to be investigated. It's pretty clear that is not the case, but I would say that this is not a showstopper. We do have some backup plans to evaluate now, if you are interested I can eventually report the results of these setups. Cheers, Diego Il 3/4/2020 6:55 PM, Andrew Hanushevsky ha scritto: > Ah, please be aware that the proxy server does not support delegation. > So, it would seema nother approach needs to be considered. > > Andy > > On Wed, 4 Mar 2020, Diego Ciangottini wrote: > >> 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] [[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