> On Jul 27, 2018, at 4:13 PM, Andrew Hanushevsky <[log in to unmask]> wrote:
>
> 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.
Yup - that's why I went to the SFS level, even though it's quite a bit more painful than the OSS layer.
>
> 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.
The capabilities are necessary due to how the process is started -- at fork, the capabilities are added to the "permitted" set but not the "effective" set. You need to add them to the effective set - short of making a direct syscall, using libcap is the best way forward. There are some newer Fedora-only kernel features that give forked processes a certain effective capability set - but, well, I don't want to wait for RHEL8. :)
My understanding is that libcap (from kernel.org) and libcap2 (a second implementation) both implement the same API in the same library name (libcap).
>
> 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?
>
Right - it simply passes through the I/O calls on an open file. To the best of my knowledge, only AFS does authorization on read()/write() for open file handles ... so this wouldn't work well for exporting an AFS target. Then again, there are many other reasons why this wouldn't work for AFS!
The setfs{u,g}id calls are only done for metadata (and open, of course).
> 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.
The biggest change is that you have to tweak *something* in the systemd unit file (or start hacking around in core Xrootd to get it to drop privileges in a certain way), meaning that you need a separate unit file. For the plugin to work, you have to have the separate unit files in the RPM and do something like this:
systemctl start xrootd-privileged@clustered
instead of:
systemctl start xrootd@clustered
I don't particularly care for a separate unit -- but then again, I would like hacking the core daemon code even less! With this approach, the functionality can be achieved within the plugin.
Brian
> 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
