You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We had an issue in EOSCMS where a user submitted some jobs doing HTTP transfers using XrdMacaroons and the identity used for storing and/or retrieving those files was different from the identity that was present in their macaroon token. Therefore, some of their transfers received misleading permission denied errors or worst, the files uploaded had a different owner.
Looking more closely into this issues, it seems the problem comes when for example the davix client tries to keep the TCP connection opened towards an endpoint - for obvious performance reasons - but while doing this it can happen that the actual requests that are sent over that link might come with different tokens encoding different permissions/owners. The provided XrdMacaroon authz plugin does a good job of extracting the user identity from the provided token but when attaching it to the XrdSecEntity object it uses the new XrdSecEntityAttr structure calling the Add method without replace:
Therefore, in case the current XrdSecEntity object had this entry already populated, the operation does not override the old value. So we end up with a request coming from a user having certain token capabilities which ultimately get mapped to a different user corresponding to a previous request.
I guess there are several "philosophical" questions here that need to be address as this behavior that makes perfect sense for the XRootD protocol, it does not seem to work so well for HTTP and tokens. But I am more interested in the practicalities here, so of course simply calling the Add method with replace would probably fix this issues, but I am also concerned that the rest of the XrdSecEntity object might remain populated with data from previous requests and this might show up somewhere else down the line in other plugins.
Looking at the XrdSciTokens library, I see that the call is properly using the replace flag, so this should be good, with the caveat of how the rest of the XrdSecEntity object looks like ...
Therefore, it would be good to have the XrdMacaroons implementation fixed (this is just a one liner) and also what are the expectation with respect to the XrdSecEntity lifetime/contents especially in the context of HTTP and tokens.
Thanks,
Elvin
The text was updated successfully, but these errors were encountered:
Hi,
We had an issue in EOSCMS where a user submitted some jobs doing HTTP transfers using XrdMacaroons and the identity used for storing and/or retrieving those files was different from the identity that was present in their macaroon token. Therefore, some of their transfers received misleading permission denied errors or worst, the files uploaded had a different owner.
Looking more closely into this issues, it seems the problem comes when for example the
davix
client tries to keep the TCP connection opened towards an endpoint - for obvious performance reasons - but while doing this it can happen that the actual requests that are sent over that link might come with different tokens encoding different permissions/owners. The provided XrdMacaroon authz plugin does a good job of extracting the user identity from the provided token but when attaching it to the XrdSecEntity object it uses the new XrdSecEntityAttr structure calling theAdd
method without replace:xrootd/src/XrdMacaroons/XrdMacaroonsAuthz.cc
Line 234 in 0169427
Therefore, in case the current XrdSecEntity object had this entry already populated, the operation does not override the old value. So we end up with a request coming from a user having certain token capabilities which ultimately get mapped to a different user corresponding to a previous request.
I guess there are several "philosophical" questions here that need to be address as this behavior that makes perfect sense for the XRootD protocol, it does not seem to work so well for HTTP and tokens. But I am more interested in the practicalities here, so of course simply calling the
Add
method with replace would probably fix this issues, but I am also concerned that the rest of the XrdSecEntity object might remain populated with data from previous requests and this might show up somewhere else down the line in other plugins.Looking at the XrdSciTokens library, I see that the call is properly using the replace flag, so this should be good, with the caveat of how the rest of the XrdSecEntity object looks like ...
xrootd/src/XrdSciTokens/XrdSciTokensAccess.cc
Line 534 in 0169427
Therefore, it would be good to have the XrdMacaroons implementation fixed (this is just a one liner) and also what are the expectation with respect to the XrdSecEntity lifetime/contents especially in the context of HTTP and tokens.
Thanks,
Elvin
The text was updated successfully, but these errors were encountered: