linux-kernel - Re: [PATCH] nfsd: Fix nfs4_disable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <172618218021.17050.8500126114376063163@noble.neil.brown.name>
Date: Fri, 13 Sep 2024 09:03:00 +1000
From: "NeilBrown" <neilb@...e.de>
To: Pali Rohár <pali@...nel.org>
Cc: "Chuck Lever" <chuck.lever@...cle.com>, "Jeff Layton" <jlayton@...nel.org>,
 "Olga Kornievskaia" <okorniev@...hat.com>, "Dai Ngo" <Dai.Ngo@...cle.com>,
 "Tom Talpey" <tom@...pey.com>, linux-nfs@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] nfsd: Fix nfs4_disable_idmapping option

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