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