 |
 |
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 or view it on GitHub: https://github.com/xrootd/xrootd/issues/1811 You are receiving this because you are subscribed to this thread. Message ID: <[log in to unmask]> ######################################################################## 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