> On Jul 5, 2024, at 9:45 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Thu, Jul 04, 2024 at 07:00:23PM +0000, Chuck Lever III wrote: >>> 3/ The current code uses the 'struct cred' of the application to look up >>> the file in the server code. When a request goes over the wire the >>> credential is translated to uid/gid (or krb identity) and this is >>> mapped back to a credential on the server which might be in a >>> different uid name space (might it? Does that even work for nfsd?) >>> >>> I think that if rootsquash or allsquash is in effect the correct >>> server-side credential is used but otherwise the client-side >>> credential is used. That is likely correct in many cases but I'd >>> like to be convinced that it is correct in all case. Maybe it is >>> time to get a deeper understanding of uid name spaces. >> >> I've wondered about the idmapping issues, actually. Thanks >> for bringing that up. I think Christian and linux-fsdevel >> need to be involved in this conversation; added. > > There is a lot more issues than just idmapping. That's why I don't > think the current approach where the open is executed in the client > can work. The right way is to ensure the open always happens in and > nfsd thread context which just pases the open file to client for doing > I/O. I have considered that approach, but I don't yet have a clear enough understanding of the idmapping issues to say whether it is going to be necessary. Just in terms of primitives, the server has svc_wake_up() which can enqueue non-transport work on an nfsd thread. Question then is what is the form of the response -- how does it get back to the "client" side. -- Chuck Lever
