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

[Bryan Burgin]

These are all good points.  The client shouldn't send a context it doesn't need, but it is.  If you would like, I can issue a bug against the call and follow up on that front.  From the server perspective: the AAPL case, as is true with the SVHDX_OPEN_DEVICE_CONTEXT prior to 3.0.2 when it was unknown, the server will ignore the context nor will it return the reply context structure and the client needs to cope with that.  However, a client prior to 3.0.2 wouldn't send a create with the RSVD context, either.  Re " Clients need to cope with the absence of reply blobs to create context they asked for in an appropriate manner", what happens probably depends on what is requested next.  If it's a tunneled SCSI request, let's say, it may be too late to do something graceful.  In the user scenarios you cited (backup, creating a VHDX, etc.), CONTEXT_[V1|V2].OriginatorFlags will be 0x00000004: SVHDX_ORIGINATOR_VHDMP "Shared virtual disk file to be opened in underlying object store" (contrasted against 0x00000001 SVHDX_ORIGINATOR_PVHDPARSER "Shared virtual disk file to be opened as a virtual SCSI disk device").  It may be worth considering only ignoring the context, if that's what you propose to do, only in that case.  However, per the spec, we believe that you should be either supporting the context (and RSVD) or failing the Create.

-----Original Message-----
From: Jeremy Allison [mailto:jra at samba.org] 
Sent: Thursday, February 25, 2016 11:14 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:55:19PM +0000, Bryan Burgin wrote:
> 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.

The problem is the server doesn't know "the client"
as stack intentions.

We only know they asked for something we don't support (yet).

Now if we had no way of telling the client we weren't giving them what they asked for I'd agree with you - returning an error would be the only way for the server to cope.

But we *do* tell the client we're not implementing this - by not returning the reply blob to the given create context we're informing the client they didn't get the feature they wanted.

Sure - they client should only add the context if it needs the server to use it - but the client should also cope appropriately with the lack of the reply context.

Essentially, the additional create contexts in
SMB2 allow an ioctl blob to be tunnelled through a create.

As we (smbd) don't know if the underlying Samba VFS that's loaded on the share supports this additional context or not, all we should do is pass the in-blobs down to the VFS module, and then return the out-blobs returned. The underlying smbd VFS should decide if it must fail the create based on the in-blob contents.

tl;dr. Clients need to cope with the absense of reply blobs to create context they asked for in an appropriate manner.

Cheers,

	Jeremy.