From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp2120.oracle.com ([156.151.31.85]:48072 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750750AbeFAVnL (ORCPT ); Fri, 1 Jun 2018 17:43:11 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: [PATCH 1/1] nfs-utils: Add check of clientaddr argument From: Chuck Lever In-Reply-To: Date: Fri, 1 Jun 2018 17:42:48 -0400 Cc: trond.myklebust@hammerspace.com, Olga Kornievskaia , Steve Dickson , Linux NFS Mailing List Message-Id: <010D5261-BC69-41A0-BBF1-F72377BB6DE4@oracle.com> References: <20180524200542.22685-1-kolga@netapp.com> <48E7EEA0-C804-4AB3-9C08-10A5B14B8976@oracle.com> <63AA3A00-6272-4D91-AC0A-30C9A169DBD1@oracle.com> <0079153E-7153-4246-AFD6-864E53100D8E@oracle.com> To: Olga Kornievskaia Sender: linux-nfs-owner@vger.kernel.org List-ID: > On May 29, 2018, at 4:53 PM, Chuck Lever = wrote: >=20 >> On May 29, 2018, at 4:07 PM, Olga Kornievskaia = wrote: >>=20 >> On Fri, May 25, 2018 at 6:35 PM, Chuck Lever = wrote: >>>=20 >>> I can think of legitimate cases where two unique NFSv4.0 >>> clients having the same IP address might mount the same >>> server. >>>=20 >>> - clientaddr=3D0.0.0.0, as mentioned above >>=20 >> I think this should be prohibited. If this is used a way to signify = to >> the server to no give out delegations, then there could be other = means >> of doing so. Let's add a mount option 'nodeleg', client would send a >> valid callback info to the server but if the option is set, then it >> will not start a callback server. That would prevent the server from >> being able to establish a callback path (which is the same thing as >> sending 0.0.0.0). >=20 > That introduces delays while the server is probing the client's > callback server. The spec specifically allows a client to send > 0.0.0.0 to signify that the server should not use callbacks. >=20 > And mount.nfs has allowed that setting for a long time. >=20 > IMO we have to continue to allow 0.0.0.0. Still thinking about this. Not using cl_ipaddr in the client ID string helps. I have a patch that does this. The question I've been wondering since the original post is "are there any other use cases where mount.nfs can't properly guess which address to provide?" That's why I was asking why your customer was using clientaddr. If we have confidence that mount.nfs is 100% reliable about choosing a good local address, except in the NAT case where we should just be disabling CB, then we could have mount.nfs strip off a user-supplied clientaddr and construct its own in all cases but the "clientaddr=3D 0.0.0.0" case (and it's IPv6 equivalent). -- Chuck Lever