 |
 |
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 the Add method without replace:
https://github.com/xrootd/xrootd/blob/016942782ef5fb15f906bb0fab84270f199015c8/src/XrdMacaroons/XrdMacaroonsAuthz.cc#L234
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 ...
https://github.com/xrootd/xrootd/blob/016942782ef5fb15f906bb0fab84270f199015c8/src/XrdSciTokens/XrdSciTokensAccess.cc#L534
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
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1