Hi all,
I have a general clarification question regarding the sec.protocol parameters for gsi authentication.
Recently we had Belle transfers failing. The cause for this was determined as a bad cert rollover in one of the remote sites. However, our site was seeing deletion errors for a longer period, even after the certificate was fixed at the remote site.
What we observed were cert accesses with missing vo/role attributes. So just seeing the requests EOS behaviour was correct in denying those accesses. What I’m wondering is if there was some certificate or mapping information cached on the mgm, so that these did not update properly (possibly due to a longer certificate validity of up to 7 days).
What I’ve found so far: are the settings in sec.protocol:
https://xrootd.slac.stanford.edu/doc/dev49/sec_config.htm#_Toc517294098
We’ve set the “exppxy” parameter like in this example (from our actual config):
sec.protocol gsi -cert:/etc/grid-security/daemon/mgm-1.eos.grid.vbc.ac.at.crt -key:/etc/grid-security/daemon/mgm-1.eos.grid.vbc.ac.at.key -gridmap:/etc/grid-security/grid-mapfile -crl:1 -d:1 -gmapopt:11 -gmapto:60 -vomsat:1 -moninfo:1 -exppxy:/var/eos/auth/gsi#<uid> -vomsfun:libXrdVoms.so -vomsfunparms:grpopt=0
Note the exppxy setting a template path to /var/eos/auth/gsi#
[root@mgm-1 ~]# ls '/var/eos/auth/'
gsi#10303 gsi#43349 gsi#45800 gsi#46149 gsi#<uid>
This corresponds to (some, not all) the mappings of uids from our user mappings (eos vid).
What is curios is also the one literally ‘gsi#’ Where I don’t understand why the uid is not replaced.
Also according to the docs, the default (not setting “exppxy”) would be to just put them to /tmp/ with a similar pattern.
My questions are:
- can there be a naming collision as multiple certs are mapped into the same file (or will the file then just hold all of the mapped certificates)?
- Would there be an advantage to setting this to “exppxy:=creds” - i.e. have it added to the XrdSecEntity object during the request (but I assume then there is no “caching”)
- why is the setting honored, when dlgpxy:opt is not set explicitly (or is the default an opportunistic setting that will deal with it, according to client’s behavior)?
Again, as of now, nothing is broken on our end, this is just an attempt to better understand the inner-workings of EOS and xrootd.
Thanks,
Best
Erich