 |
 |
Sure, I'd like test it. I'll keep an eye on release communication, but, in case I'd miss it, please feel free to contact me! Thanks, Diego Il 3/5/2020 10:50 PM, Andrew Hanushevsky ha scritto: > Hi Diego, > > Not yet. It's a bit of work to make this change fully backward > compatible. However, I hope to have it in there in a couple of weeks. > Sounds like you are willing to test it! > > Andy > > On Thu, 5 Mar 2020, Diego Ciangottini wrote: > >> That would be very promising. Is this something already available in >> the current R5 rc? >> >> Diego >> >> Il 3/5/2020 9:01 AM, Andrew Hanushevsky ha scritto: >>> 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