On Fri, 05 Jul 2024, Chuck Lever III wrote: > > > > 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. I can't see that nfsd pays any attention to uid namespaces. I think it always uses the init_ns. So we would need to ensure the client credential was interpreted against the init namespace. I still have made time to understand what this means in practice. > > 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. I think it would be quite easy to establish a new work-queue (lwq?) that clients can attach a request structure too before calling svc_wake_up(), and which the nfsd thread would examine after svc_recv() returns. This request structure would include the filehandle, credential, possible other context, place to store the result, and a completion. The server thread would complete the completion and the client, after queuing the request, would wait for the completion. So: easy enough to do if it turns out to be necessary. NeilBrown > > > -- > Chuck Lever > > >
