 |
 |
On Wed, 4 Mar 2020, Brian P Bockelman wrote: > This sounds very promising! Yes, it was written specifically to handle multi-mode authorization which SciTokens essentially introduces (didn'y know Macaroons did the same). > (One aside on the manual text for this - I was very confused by this > sentence in the manual: > ``` > ++ The specified plug-in should stack on top of the existing > plug-in or default. Once specified, it cannot be overridden by a > subsequent directive, > ``` > > I read this as saying "this can only be used once", which somewhat > contradicts what you wrote above. A clarification in the manual would > be appreciated.) OK, poor wording on my part. You can always override the base plugin with a subsequent directive. That's the one without a "++". You can't eally extend this o any plugin that was stacked with a "++". Once stacked, it reains stacked. All you can do is add another one to the stack. That's what I was trying to say. So, I'll reword that in all the places it appears. I say that because the syntax was extended to most plugins. Yes, you can stack all the plugins that matter at he mment and we can extend it to additional ones should the need arrise. > The second unpleasant piece in this code is the fact that, within the > HTTP handler, we need to have access to the `XrdAccAuthorize` object > used by the OFS to generate the appropriate permissions for the > Macaroon. Yes, I see the problem. I was going to add an "Access(const path[, mode])" to the whole thing so you can get that information. Then I had second thoughts as I didn't see who would use that. I guess I was wrong here. I can add that feature and it will be available via the bridge as an fsctl() operation. I assume that Access() as defined by POSIX will do the trick for you. Either it says yes or no or returns the mode bits allowed. Right? > Is there such a way to do that? This is currently accomplished by > directly constructing the object and via a reimplementation of the > ofs.authlib` logic. There's not much gain if we significantly clean up > this usage only to add more complexity elsewhere. What you point out > only helps the case of making an authorization object for the `ofs` and > not recreating it in the plugin. Yes, I am trying to desparately avoid doing this and I think we can do that pretty easily. > Thanks! You're welcome. Andy -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/pull/1147#issuecomment-595032250 ######################################################################## 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