From: Peter Staubach Subject: Re: [PATCH] nfs-utils: Handle authentication flavour order properly Date: Fri, 07 Mar 2008 13:27:01 -0500 Message-ID: <47D188F5.9060005@redhat.com> References: <629ABBF6-C368-44AC-B4B9-471296229325@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: Chuck Lever , trond.myklebust@fys.uio.no, linux-nfs@vger.kernel.org To: bc Wong Return-path: Received: from mx1.redhat.com ([66.187.233.31]:57704 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932449AbYCGS2N (ORCPT ); Fri, 7 Mar 2008 13:28:13 -0500 In-Reply-To: Sender: linux-nfs-owner@vger.kernel.org List-ID: bc Wong wrote: > On Fri, Mar 7, 2008 at 8:16 AM, Chuck Lever wrote: > >> Hi BC- >> >> >> On Mar 6, 2008, at 10:08 PM, bc Wong wrote: >> > There were 2 things wrong with auth flavour ordering: >> > - Mountd used to advertise AUTH_NULL as the first flavour on >> > the list, which means that it prefers AUTH_NULL to anything >> > else (as per RFC 2623 section 2.7). >> > - Mount.nfs used to scan the returned list in reverse order, >> > and stopping at the first AUTH_NULL or AUTH_SYS encountered. >> > If a server advertises (AUTH_SYS, AUTH_NULL), it will by >> > default choose AUTH_NULL and have degraded access. >> >> This patch addresses problems only in the legacy part of the user >> space mount.nfs command. Since 2.6.24 NFS mount option parsing is >> handled in the kernel instead. >> >> I don't think the new in-kernel mount client even supports receiving >> a list of auth flavors from the server. Do you have an equivalent >> patch for that? If you'd like help we can discuss it off-line. >> > > Hi Chuck, > > Sorry I was totally unaware of the the migration of option parsing > into the kernel. At first glance, it seems that the client will just > insist on using whatever is specified in `sec=', even thought the > server does not advertise it. The server would probably return an > NFS RPC error, instead of a MOUNT error. I can look into fixing > the kernel client as well. > > I'd still like the submitted patch to be considered. It's quite bad > that mount.nfs would encounter (AUTH_SYS, AUTH_NULL) and > pick the latter. I don't think that the client can generate AUTH_NONE, can it? I thought that the client generated AUTH_SYS even if the server specified AUTH_NONE? If you make changes in this area, please ensure that the server exporting AUTH_NONE still works. Thanx... ps