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