 |
 |
Hi Brian, Interesting. We were going to roll that capability into the base next year as extensions to the oss layer. Doing that requires some non-abi compatible changes to the oss API which we'd introduce in R 5.0 where we are alllowed to break ABI. That said, a couple of questions 1) Why the dependence on libcap? It may be problematic as there is libcap and libcap2 and some platforms support or the other but not both by my search. Of course, some platforms don't support it at all. 2) I assume you use setfsuid() and setfsgid() to do the magic. Reading through the docs, that only needs to be done for file metadata operations because it shouldn't matter what uid/gid you have to do the actual I/O on an open file. So, why is that not the case here? So, given the above does that change your opinion in any way? I think it's a good base capability to have but it's not clear the best way to do it. Once we have the plugin in the code base it would be hard to remove it. So, like you, I don't have a strong feeling one way or the other right now but may after the weekend is over. Andy On Fri, 27 Jul 2018, Brian Bockelman wrote: > Hi all, > > For OSG, we have created the "xrootd-multiuser" plugin, a SFS plugin > that does per-thread switching of the fsid (mapping the name in the > XrdSecEntity to the UID of the corresponding Unix username) prior to > doing IO operations. It's served us well internally and is starting to > get the attention of other sites that run Xrootd on top of POSIX storage > (for example, Florida). > > The package (https://github.com/bbockelm/xrootd-multiuser > <https://github.com/bbockelm/xrootd-multiuser>) consists of a SFS plugin > that wraps around the native SFS implementation and a set of systemd > units that startup Xrootd with the appropriate privileges to invoke > setfsuid. There is a build and runtime dependency on libcap, which is a > fairly common base library. > > I think it's time to upstream this plugin. As with xrootd-macaroons, > there's a question of whether it should be a standalone package or part > of Xrootd base. Unlike xrootd-macaroons, I don't have as strong an > opinion as I feel the scope is a bit more narrow. > > Thoughts? > > 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 > ######################################################################## 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