On Wed, 2024-07-03 at 11:36 -0400, Mike Snitzer wrote: > On Wed, Jul 03, 2024 at 03:24:18PM +0000, Chuck Lever III wrote: > > > > > > > On Jul 3, 2024, at 11:18 AM, Christoph Hellwig > > > <hch@xxxxxxxxxxxxx> wrote: > > > The actual way > > > to find the file struct still would be nasty, but I'll try to > > > think of > > > something good for that. > > > > It is that very code that I've asked to be replaced before this > > series can be merged. We have a set of patches for improving > > that aspect that Neil is working on now. > > > > When Mike presented LOCALIO to me at LSF, my initial suggestion > > was to use pNFS. I think Jeff had the same reaction. > > No, Jeff suggested using a O_TMPFILE based thing for localio > handshake. But he had the benefit of knowing NFSv3 important for the > intended localio usecase, so I'm not aware of him having pNFS design > ideas. > The other problem with doing this is that if a server is running in a container, how is it to know that the client is in different container on the same host, and hence that it can give out a localio layout? We'd still need some way to detect that anyway, which would probably look a lot like the localio protocol. > > IMO the design document should, as part of the problem statement, > > explain why a pNFS-only solution is not workable. > > Sure, I can add that. > > I explained the NFSv3 requirement when we discussed at LSF. > > > I'm also concerned about applications in one container being > > able to reach around existing mount namespace silos into the > > NFS server container's file systems. Obviously the NFS protocol > > has its own authorization that would grant permission for that > > access, but via the network. > > Jeff also had concerns there (as did I) but we arrived at NFS having > the ability to do it over network, so doing it with localio > ultimately > "OK". That said, localio isn't taking special action to escape mount > namespaces (that I'm aware of) and in practice there are no > requirements to do so. The one thing I think we need to ensure is that an unauthorized NFS client on the same kernel can't use this to bypass export permission checks. IOW, suppose we have a client and server on the same host. The server allows the client to access some of its exports, but not all. The rest are restricted to only certain IP addresses. Can the client use its localio access to bypass that since it's not going across the network anymore? Maybe by using open_by_handle_at on the NFS share on a guessed filehandle? I think we need to ensure that that isn't possible. I wonder if it's also worthwhile to gate localio access on an export option, just out of an abundance of caution. -- Jeff Layton <jlayton@xxxxxxxxxx>
