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
|