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
|