 |
 |
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