Re: server-to-server copy by default

From: Bruce Fields <bfields@fieldses.org>
To: dai.ngo@oracle.com
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	Steve Dickson <steved@redhat.com>,
	Olga Kornievskaia <olga.kornievskaia@gmail.com>,
	Chuck Lever <chuck.lever@oracle.com>
Subject: Re: server-to-server copy by default
Date: Fri, 22 Oct 2021 08:58:35 -0400	[thread overview]
Message-ID: <20211022125835.GA11434@fieldses.org> (raw)
In-Reply-To: <78839450-8095-01ae-53e8-f0ebf941b5a5@oracle.com>

On Thu, Oct 21, 2021 at 11:34:44PM -0700, dai.ngo@oracle.com wrote:
> On 10/21/21 7:02 AM, Bruce Fields wrote:
> >Thanks for the persistence:
> >
> >On Wed, Oct 20, 2021 at 10:00:41PM -0700, dai.ngo@oracle.com wrote:
> >>The attack can come from the replies of the source server or requests
> >>from the source server to the destination server via the back channel.
> >>One of possible attack in the reply is BAD_STATEID which was handled
> >>by the client code as mentioned by Olga.
> >>
> >>Here is the list of NFS requests made from the destination to the
> >>source server:
> >>
> >>         EXCHANGE_ID
> >>         CREATE_SESSION
> >>         RECLAIM_COMLETE
> >>         SEQUENCE
> >>         PUTROOTFH
> >>         PUTHF
> >>         GETFH
> >>         GETATTR
> >>         READ/READ_PLUS
> >>         DESTROY_SESSION
> >>         DESTROY_CLIENTID
> >>
> >>Do you think we should review all replies from these requests to make
> >>sure error replies do not cause problems for the destination server?
> >That's the exactly the sort of analysis I was curious to see, yes.
> 
> I will go through these requests to see if is there is anything that
> we need to do to ensure the destination does not react negatively
> on the replies.
> 
> >
> >(I doubt the PUTROOTFH, PUTFH, GETFH, and GETATTR are really necessary,
> >I wonder if there's any way we could just bypass them in our case.  I
> >don't know, maybe that's more trouble than it's worth.)
> 
> I'll take a look but I think we should avoid modifying the client
> code if possible.
> 
> >
> >>same for the back channel ops:
> >>
> >>         OP_CB_GETATTR
> >>         OP_CB_RECALL
> >>         OP_CB_LAYOUTRECALL
> >>         OP_CB_NOTIFY
> >>         OP_CB_PUSH_DELEG
> >>         OP_CB_RECALL_ANY
> >>         OP_CB_RECALLABLE_OBJ_AVAIL
> >>         OP_CB_RECALL_SLOT
> >>         OP_CB_SEQUENCE
> >>         OP_CB_WANTS_CANCELLED
> >>         OP_CB_NOTIFY_LOCK
> >>         OP_CB_NOTIFY_DEVICEID
> >>         OP_CB_OFFLOAD
> >There shouldn't be any need for callbacks at all.  We might be able to
> >get away without even setting up a backchannel.  But, yes, if the server
> >tries to send one anyway, it'd be good to know we do something
> >reasonable.
> 
> or do not specify the back channel when creating the session somehow.
> I will report back.

Thank you, Dai!

--b.