Return-Path: linux-nfs-owner@vger.kernel.org Received: from aserp1040.oracle.com ([141.146.126.69]:34535 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752641Ab3KLQrC convert rfc822-to-8bit (ORCPT ); Tue, 12 Nov 2013 11:47:02 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: [PATCH] Adding the nfs4_secure_mounts bool From: Chuck Lever In-Reply-To: <52825648.5090907@RedHat.com> Date: Tue, 12 Nov 2013 11:46:42 -0500 Cc: "Myklebust, Trond" , Linux NFS Mailing List Message-Id: <3DB05606-0818-45DF-88FE-7045B6F026F8@oracle.com> References: <1384037221-7224-1-git-send-email-steved@redhat.com> <52811CBB.3070204@RedHat.com> <5281290B.6000201@RedHat.com> <52814876.7080604@RedHat.com> <5281618A.1050604@RedHat.com> <784A1C68-59DA-4248-AF91-BAF472CDD37E@oracle.com> <52825648.5090907@RedHat.com> To: Steve Dickson Sender: linux-nfs-owner@vger.kernel.org List-ID: On Nov 12, 2013, at 11:24 AM, Steve Dickson wrote: > > > On 12/11/13 11:09, Chuck Lever wrote: >>> In the past, if admins want rpc.gssd in the mount path they had to configure it. >>>> Now we are silently adding, yet another, daemon to the mount path and if >>>> rpc.gssd starts falling on its face, I think it will be difficult to debug, >>>> since the daemon is not expected to be there... >> Our only real choice here is to fix gssd. Anything else is punting the problem down the road. >> > No. The last there was a daemon was involved in all NFS client mounts > (at least that I can remember) was when lockd was a user level daemon. > The main reason it was ported to the kernel was to get ride of the > bottle neck it caused... Now we adding similar bottle neck back?? > > Architecturally, put a daemon in the direct NFS mount path just does > not make sense... IMHO... Don't be ridiculous. rpc.gssd is ALREADY in the direct mount path for all Kerberos mounts, and has been for years. Forget lease management security for a moment, and consider this: There is no possibility of moving forward with a secure NFS solution on Linux if we can't depend on rpc.gssd. Therefore, our only real choice if we want Kerberos to be a first class NFS feature on Linux is to make sure rpc.gssd works reliably. Last I checked, we are making a robust effort to harden Kerberos support for NFS. So I don't see any contradiction here. Now, specifically regarding when rpc.gssd is invoked for lease management security: it is invoked the first time each new server is contacted. If you mount the same server many times, there should be just one upcall. And, if auth_rpcgss.ko is not loaded, there will be no upcall. Ever. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com