Print

Print


I don't think the cache currently has a way to use the delegated credential, even if the client allows to delegate.

 

--

Wei Yang  |  [log in to unmask]  |  650-926-3338 (O)

 

 

From: <[log in to unmask]> on behalf of Diego Ciangottini <[log in to unmask]>
Organization: INFN
Date: Wednesday, March 4, 2020 at 9:47 AM
To: Michal Kamil Simon <[log in to unmask]>, xrootd-l <[log in to unmask]>
Subject: Re: XrdSecGSIDELEGPROXY ignored by xrdcp

 

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