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
