Re: server-to-server copy by default

[Bruce Fields <bfields@fieldses.org>]

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 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.)

> 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.

--b.