Re: [PATCH] Adding the nfs4_secure_mounts bool

From: Steve Dickson <SteveD@redhat.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: "Myklebust, Trond" <Trond.Myklebust@netapp.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] Adding the nfs4_secure_mounts bool
Date: Mon, 11 Nov 2013 16:13:26 -0500	[thread overview]
Message-ID: <52814876.7080604@RedHat.com> (raw)
In-Reply-To: <E0FBCF46-C70F-41E5-BA67-48406253CD7E@oracle.com>

On 11/11/13 15:33, Chuck Lever wrote:
>>>
>>> We have workarounds already that work on every kernel since 3.8.
>>>
>> The one that logs 5 to 20 lines (depending on thins are setup or not)
>> per mount? That does work in some environments but no all. ;-)
> 
> When does running rpc.gssd not work?
Define "work"... ;-) Logging 20 error messages on every mount
when the keytab does not exist is not working or not very well.... IMHO..
> 
>> Or am I missing one? Please tell me I am!!! :-) 
> 
> OK: You're missing one.
Thank you... 

> 
> Client configurations that have auth_rpcgss.ko loaded but do not run rpc.gssd are, quite simply, broken.  The gss upcall will not work in that configuration.  There is no reason to load auth_rpcgss.ko if user space does not have rpc.gssd enabled and running.
> 
> This has been a problem for a very long time, but use cases where the 15 second upcall timeout is encountered have until recently been infrequent, and only occur in situations where the mount options don't work anyway, so no one has bothered to address it.
> 
> This broken configuration is due to incorrect system initialization scripts.
Which initialization scripts are you referring to?

> 
> If an administrator chooses not to run rpc.gssd, then auth_rpcgss.ko should not be loaded.  The kernel deals quite correctly when auth_rpcgss.ko is not loaded -- GSS flavors are simply not supported, and the kernel uses AUTH_SYS by default for everything.  (Right there is your magical administrative interface for controlling what security flavors are used and supported).
> 
> But the current init scripts load auth_rpcgss.ko unconditionally.  Thus any gss upcall will fail until rpc.gssd is started.
> 
> With upstream kernel commit 4edaa308 (and following) I added a use case that exposes the upcall timeout much more often.  It's a latent bug, but we now hit it during the first mount after every client reboot, so it is noticeable to anyone who leaves nfs-secure.service disabled.
> 
> Therefore the scenario we want to avoid is where auth_rpcgss.ko is loaded, but rpc.gssd is not running.  There are two obvious ways to avoid this scenario:
> 
>   A.  If auth_rpcgss.ko is loaded unconditionally, make sure rpc.gssd is running unconditionally (and cull the warnings)
> 
>   B.  If you do not want to run rpc.gssd, make sure auth_rpcgss.ko is not loaded
Isn't the case that nfsd will also loads auth_rpcgss. So if server was started we
would be right back to the 15 sec delay?

steved.

> 
> Both of these workarounds are configuration changes, not code changes.  B. is accomplished simply by blacklisting auth_rpcgss.ko.
> 
> We could go a step further and remove the module alias added by upstream kernel commit 71afa85e to prevent the kernel from loading auth_rpcgss.ko automatically, and then make sure the nfs-secure.service script (and the server-side equivalent) loads auth_rpcgss.ko before starting rpc.gssd.
> 
> Since you are opposed to running rpc.gssd, blacklisting auth_rpcgss.ko is the easy choice.  Adding auth_rpcgss.ko to the module blacklist is no more difficult than setting a kernel module parameter or toggling nfs-secure.service.
> 
> However, IMO, in the long run Linux should be installed with rpc.gssd running unconditionally, or dynamically start-able by mount.nfs (like statd works today).  We cannot guess a priori whether a user or administrator will want NFS support for GSS flavors, just as we cannot guess a priori whether the user wants support for NFSv3.
> 
> Yet we always have NFSv3 support available.  Likewise, support for GSS should always be available, and there really is no good reason any more not to leave it running all the time.
> 
> As Trond points out, NFSv4 implementations are required to implement GSS security.
> 