I understand that this flag disables SSS auth when doing an XRootD
transfer with another FST node.
In this thread
Elvin made the following comment “This env can be used for instances that you control (both source and destination) but is not a recommended way for doing TPC with external sites” which sounds like against using the EOS_FST_NO_SSS_ENFORCEMENT
yes, if you use an external proxy xrootd to do transfers, you can configure the MGM to redirect TPC transfers to that one. EOS_FST_NO_SSS_ENFORCEMENT is not really an issue. The only ‘issue’ is, that if you do a TPC transfer in XRootD4, the open path + the single file token is transferred unencrypted on the wire. Once we all run Xrootd5 the open path the file token will also be encrypted, but this has really nothing to do with using sss or not. You can connect an FST in any case without sss. On the other hand the token is valid for a limited time and only grants read or write access to a single file, so the ‘risk’ is not really very high.
I noticed that while the MonALISA TPC test had been green from some time, at some point it started failing again with the a “Permission denied” error which looks like the one below. It is not the “Auth failed” error which I got in the beginning before finalising the config.
I do notice the incorrect “uid=0 gid=0” in the error. I wonder why this happens?
Is there some funny cacheing going on with the auth? I have noticed that occassionaly “eos whoami” shows me as “daemon” whereas it should show me as root according to