 |
 |
Hi Diego, Please be aware that in R5 we will have the capability to recreate the original credentials between a proxy server and the origin server as long as the proxy and origin use "sss" authentication between them. We already do this for FUSE. This is quite workable in a local site (the main use case for EOS). So, perhaps, this will be sufficient for what ou want to do. Andy On Thu, 5 Mar 2020, Diego Ciangottini wrote: > 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