Using GSI authentication from random hosts

Is there a reason not to use GSI authentication for xrdcp operations from random hosts?

I installed xroot on my Mac so I could transfer files from it to a test EOS instance. I can’t use Unix auth since my uid will not be the same and we aren’t using krb for EOS right now. I figured the least intrusive thing would be to use GSI authentication since I have my cert on the Mac and the MGM is set up to allow GSI auth from anywhere:

#Anyone can perform securely authenticated actions
sec.protbind * only gsi sss krb5

The problem is, I get a zero-length file on the instance and then a “file exists” error ending the operation. If I use ‘-f’ I get a ‘redirect limit has been reached’ error. What I believe is happening is the MGM is accepting the GSI credential and somehow communication between the MGM and FST is not set up properly to transfer the actual file contents. I can do ‘xrdfs root://… ls’ operations just fine.

So two questions. Is there a reason NOT to use this kind of setup? If it is acceptable, what needs to be done to allow this to work properly?

It is also possible I’m not too clear on how GSI auth works and I’m just missing something.


Dan Szkola

You should not force GSI authentication on client side by setting XrdSecPROTOCOL, because the FST require unix authentication because the rely only on authorization by a signed URL from the MGM.

Ah, not sure why I had not tried that. I took the XrdSecPROTOCOL off the command and it worked.

So I assume I am using GSI to authenticate to the MGM. GSI will map my cert to the correct username/UID, so I assume the MGM is capable then of taking that and using unix auth to transact with the FST? I just want to be sure I understand what is happening.

Thanks for the quick solve.