> On Jul 2, 2018, at 3:50 PM, Andrew Hanushevsky <[log in to unmask]> wrote:
>
> Thanks Brian, I hope you had a restful vacation! Do you know what the package name will be?
It is libmacaroons (https://koji.fedoraproject.org/koji/buildinfo?buildID=1092585 <https://koji.fedoraproject.org/koji/buildinfo?buildID=1092585>). This got merged to stable this morning, but hasn't hit my local mirror yet. I'm assuming it's only a matter of hours.
> I assume, then, you will not be checking the code into the xrootd.org repo named xrootd-macaroons (https://github.com/xrootd/xrootd-macaroons <https://github.com/xrootd/xrootd-macaroons>), right?
Yes, that'd be my preference.
>
> As for API changes, now is the time to explore them as we are heading tnto R5 territory where we can break ABI’s. From what I can see, it would be good to have fields in the XrdSecEntity structure where you could point to the macaroon and it’s length. Likely the same problem for SciTokens, though that one would be just as easy to pass via a CGI element that avoids the whole problem in the first place. Thought?
Personally, I prefer passing tokens via the CGI elements. I see the XrdSecEntity as authorizing the *session* while the token only authorizes a single operation.
For the HTTPS case, no client certificate is used so the XrdSecEntity is set up (correctly!) for the anonymous user. However, the token is passed along with each individual request, so the authorization layer has to handle things on a request-by-request basis.
It's more complicated than that, however.
The problem case is when Xrootd is used on top of a shared filesystem that has its own UID/GID concept separate from XRootD. The filesystem plugins tend to utilize information from XrdSecEntity to translate the Xrootd user and group to the filesystem's user and group.
In the case of SciTokens, the admin provides this mapping ("CMS-issued tokens map to the CMS user").
In the case of macaroons, we will embed this in the macroon itself.
However, both cases achieve this by modifying the const XrdSecEntity passed to the authorization layer... yuck!
Not only is it hacky and not guaranteed to work if Xrootd internals change, it's the wrong abstraction: the session object is mutated for every request.
I guess the ideal world would be to make the XrdSecEntity have a request-level scope for XrdOfs requests (meaning there's a clear way to mutate it in the authorization layer) or have a separate per-request authorization object. The latter can probably be done by not breaking ABIs. The latter is cleaner, but a lot of ABI breakage for minor gain.
Brian
########################################################################
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
