Re: server-to-server copy by default

[Bruce Fields <bfields@fieldses.org>]

On Mon, Nov 01, 2021 at 10:37:11AM -0700, dai.ngo@oracle.com wrote:
> 
> On 10/21/21 11:34 PM, dai.ngo@oracle.com wrote:
> >On 10/21/21 7:02 AM, Bruce Fields wrote:
> >>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.
> 
> still need to be done.
> 
> >
> >>
> >>(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.
> 
> We can not disable the back channel of the SSC v4.2 mount since it might
> share the same connection with a regular NFSv4.2 mount from the destination
> to the source server.

Hm.

Well, now that I think of it, a backchannel is probably required for the
SSC case anyway.  (I think CB_RECALL_SLOT is mandatory to support?)

--b.