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
|