[cifs-protocol] [REG:116022413751567 ] Response to SVHDX_OPEN_DEVICE_CONTEXT[_V2] when shared VHDX is not supported

[Bryan Burgin]

It would be helpful to consider "the client" as more than a single entity and instead as layers that are isolated.  At the SMB2 layer, we're just plumbing.  Some application higher up plumbed down a CreateFile that has a CreateContext that it faithfully sends it across the wire.  Why it did so and what else it might be expecting cannot be known to us, so we cannot know if there is behavior it is expecting on the server endpoint based on stuff it sent in a particular context.  That discussion is in a purely generalized scope.  Drilling into this particular context there may be some opportunities to make assumptions, but even in that, we should be careful.  The right way to resolve this, from my viewpoint, is to have application layers only add this context if it really needs the server to behave differently because of its existence of the context and to exclude the context when that doesn't matter.  In some cases (i.e., it expects to open the VHDX in shared mode and do SCSI tunneled requests) it may very much care.  In other situations, it may not care at all.  I'm suggesting that doing a blanket ignore may cause unintended consequences now or later that should cause us some pause now.  Possibly, adding a bit more intelligence than a blanket action to always ignore.  I have a few ideas that I'm letting percolate.

B.  

-----Original Message-----
From: Jeremy Allison [mailto:jra at samba.org] 
Sent: Thursday, February 25, 2016 10:29 AM
To: Bryan Burgin <bburgin at microsoft.com>
Cc: Uri Simchoni <uri at samba.org>; cifs-protocol at lists.samba.org; MSSolve Case Email <casemail at microsoft.com>; jra at samba.org
Subject: Re: [cifs-protocol] [REG:116022413751567 ] Response to SVHDX_OPEN_DEVICE_CONTEXT[_V2] when shared VHDX is not supported

On Thu, Feb 25, 2016 at 06:13:58PM +0000, Bryan Burgin wrote:
> Hi Uri,
> 
> Some additional research.
> 
> This is a case where an upper-layer application is adding the Context and SMB2 is just the plumbing.  The danger with ignoring the Context altogether is you (you being anyone in the plumbing as we are including us) don't know why the application is adding the context.  This is the same code that in 2013 assumed that if the negotiated context was of a sufficient level where Resiliency could be supported then the application layer assumed that it must be (i.e., it sent the resiliency request and did a hard failure if the response was not successful).  The fix back then was to still ask for resiliency, but not consider its absence to be a hard failure.
> 
> Ultimately, I think that the statement in [MS-SMB2] is correct in that you should fail the Create and that the right fix (potentially) is to request another fix in our code to not add the RSVD context if it's not needed.
> 
> I know you already pushed a Samba fixed based on my preliminary comments.  We may want to discuss that more and possibly roll that back or refine it.

Hang on a minute. Can't the client detect that the SVHDX_OPEN_DEVICE_CONTEXT was ignored on the Create as we won't be returning any SVHDX_OPEN_DEVICE_CONTEXT_RESPONSE or
SVHDX_OPEN_DEVICE_CONTEXT_V2 blob ?

It still seems that ignoring this if we
don't support makes sense to me.

Jeremy.