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
|