Re: [PATCH] nfsd: Fix nfs4_disable_idmapping option

[NeilBrown]

On Fri, 13 Sep 2024, Pali Rohár wrote:
> On Friday 13 September 2024 08:26:02 NeilBrown wrote:
> > On Fri, 13 Sep 2024, Pali Rohár wrote:
> > > NFSv4 server option nfs4_disable_idmapping says that it turn off server's
> > > NFSv4 idmapping when using 'sec=sys'. But it also turns idmapping off also
> > > for 'sec=none'.
> > > 
> > > NFSv4 client option nfs4_disable_idmapping says same thing and really it
> > > turns the NFSv4 idmapping only for 'sec=sys'.
> > > 
> > > Fix the NFSv4 server option nfs4_disable_idmapping to turn off idmapping
> > > only for 'sec=sys'. This aligns the server nfs4_disable_idmapping option
> > > with its description and also aligns behavior with the client option.
> > 
> > Why do you think this is the right approach?
> 
> I thought it because client has same configuration option, client is
> already doing it, client documentation says it and also server
> documentation says it. I just saw too many pieces which agreed on it and
> just server implementation did not follow it.
> 
> And to make mapping usable, both sides (client and server) have to agree
> on the configuration.
> 
> So instead of changing also client and client's documentation it is
> easier to just fix the server.
> 
> > If the documentation says "turn off when sec=sys" and the implementation
> > does "turn off when sec=sys or sec=none" then I agree that something
> > needs to be fixed.  I would suggest that the documentation should be
> > fixed.
> > 
> > From the perspective of id mapping, sec=none is similar to sec=sys.
> 
> It is similar, but quite different. With sec=sys client sends its uid
> and list of gids in every (RPC) packet and server authenticate client
> (and do mapping) based on it. With sec=none client does not send any uid
> or gid. So mostly uid/gid form is tight to sec=sys.
> 

With sec=none I don't think that any mapping makes sense except to map
all uids and gids to "none" or similar.

The documented purpose of nfs4_disable_idmapping is to "ease migration
from NFSv2/v3".  That suggests that where relevant it should behave
mostly like v2/v3.

I don't feel strongly about this.  You appear to be actually using
AUTH_NONE authentication.  What behaviour would work best for your
use-case, and why?

NeilBrown