On Fri, 05 Jul 2024, Dave Chinner wrote: > On Thu, Jul 04, 2024 at 07:00:23PM +0000, Chuck Lever III wrote: > > > > > > > On Jul 3, 2024, at 6:24 PM, NeilBrown <neilb@xxxxxxx> wrote: > > > > > > > > > I've been pondering security questions with localio - particularly > > > wondering what questions I need to ask. I've found three focal points > > > which overlap but help me organise my thoughts: > > > 1- the LOCALIO RPC protocol > > > 2- the 'auth_domain' that nfsd uses to authorise access > > > 3- the credential that is used to access the file > > > > > > 1/ It occurs to me that I could find out the UUID reported by a given > > > local server (just ask it over the RPC connection), find out the > > > filehandle for some file that I don't have write access to (not too > > > hard), and create a private NFS server (hacking nfs-ganasha?) which > > > reports the same uuid and reports that I have access to a file with > > > that filehandle. If I then mount from that server inside a private > > > container on the same host that is running the local server, I would get > > > localio access to the target file. > > This seems amazingly complex for something that is actually really > simple. Keep in mind that I am speaking from having direct > experience with developing and maintaining NFS client IO bypass > infrastructure from when I worked at SGI as an NFS engineer. > > So, let's look at the Irix NFS client/server and the "Bulk Data > Service" protocol extensions that SGI wrote for NFSv3 back in the > mid 1990s. Here's an overview from the 1996 product documentation > "Getting Started with BDSpro": > > https://irix7.com/techpubs/007-3274-001.pdf Interesting work. Thanks for the pointer. It appear to me that BDS uses a separate network protocol - possibly over a separate TCP connection or even a separate fabric - to connect client to server, and this protocol is tuned for high throughput data transfer and nothing else. Makes perfect sense. It would seem to still use the IP address (or similar NFS-style mechanism) to authenticate each party to the other and to establish a path for the data to flow over. This is the question facing localio in the text of mine that you quote above. We don't want a network data flow. We want to hand over a file descriptor (or 'struct file'). There is no standard way to achieve this over an IP-connected channel. So we are creating one. The proposed protocol is to send a unique number over the IP-connected channel, and use that to achieve rendezvous between the in-kernel client and the in-kernel server. The interesting questions are around how unique this number should be, which direction it should travel, and whether anything else other than the file descriptor should be passed through when the kernel sides rendezvous. I don't think the documentation on BDS sheds any particular light on this question. Thanks, NeilBrown
